beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
teddydd has quit [Ping timeout: 240 seconds]
razzy has joined #picolisp
teddydd has joined #picolisp
razzy has quit [Ping timeout: 265 seconds]
razzy has joined #picolisp
cranium has joined #picolisp
razzy has quit [Ping timeout: 240 seconds]
razzy has joined #picolisp
rob_w has joined #picolisp
razzy has quit [Ping timeout: 240 seconds]
razzy has joined #picolisp
razzy has quit [Ping timeout: 265 seconds]
razzy has joined #picolisp
razzy has quit [Ping timeout: 252 seconds]
razzy has joined #picolisp
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
razzy has quit [Ping timeout: 252 seconds]
razzy has joined #picolisp
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
aw- has quit [Ping timeout: 252 seconds]
rob_w has quit [Remote host closed the connection]
rob_w has joined #picolisp
rob_w has quit [Remote host closed the connection]
razzy has quit [Ping timeout: 240 seconds]
razzy has joined #picolisp
razzy has quit [Ping timeout: 240 seconds]
razzy has joined #picolisp
clacke has quit [Read error: Connection reset by peer]
wineroots has quit [Remote host closed the connection]
<beneroth> Regenaxer, interesting discussion on mailing list about (struct) and (native)
<beneroth> Currently I agree with your notion about keeping magic out of this functions, and but the "smart" (or possibly ISO C compliant) part in a higher level function ("next substrate layer" as in Eric Normand explains that old Lisp paper), so the programmer can choose to invoke the magic or not
<beneroth> hmm..nevermind, I write it into ML myselrf
<Regenaxer> Hi beneroth!
<beneroth> hey Regenaxer :)
<beneroth> still up?
<Regenaxer> yes, exactly, a higher level could take care of "int"s
<Regenaxer> and alignment
<Regenaxer> but struct must be so flexible
<beneroth> is (struct) really only useful for (native) ?
<Regenaxer> It is a preliminary optimization
<beneroth> I haven't worked much with both
<Regenaxer> yes, a lot
<Regenaxer> @lib/net.l in pil21 depends on it a lot
<Regenaxer> on 'struct'
<beneroth> but reading it again, I got the idea that maybe (struct) could also be handy when dealing with binary network protocols or binary file formats, unrelated to C FFI, no?
<beneroth> maybe nonsense
<Regenaxer> it is handy, yes
<Regenaxer> it can manipulate any buffer data
<Regenaxer> so Jasons assumption that (1 . 4) means "int 4" is wrong
<Regenaxer> you can also store (1 . 3)
<beneroth> I've dealt with binary network protocols before, using picolisp. struct didn't exist back then, I think. so just a lot of shifting around (the format was 32 bit aligned, but within those 32 bits it had segments splitting on stuff like 5 bits)
<Regenaxer> 5 bits is just part of a byte
<Regenaxer> but struct may access 5 bytes in one piece
<Regenaxer> cannot be done with Jason's assumptions about alignments
<beneroth> mail sent
<beneroth> well
<Regenaxer> cool, thanks!
<beneroth> I believe (as I wrote) you/Cesar/Andra read that sentence about "suitable for passing to C" very different. you mean it as a very general statement, and they mean it as "makes sure your stuff meets the "usual" expectations a C program has according to standard"
<beneroth> could that be?
<Regenaxer> Perhaps, but my use case includes any
<Regenaxer> having implied alignments wont
<beneroth> @layers: yeah stratified designs. DSLs. no magic in low level fundamental functions - else you need endless many parameters to configure its behavior.better multiple functions then.
<Regenaxer> T
<beneroth> Regenaxer, well most C/C++ code I saw didn't adhere really to standard, but to what their compiler allowed.
<beneroth> maybe they have another experience/niche in the big C world :)
<Regenaxer> I think the current way is the most general
<beneroth> oh I agree
<beneroth> still more specific helper functions might be warranted, this puzzling of native parameters is still kinda developer time intensive.
<Regenaxer> At least when we want to handle types in a platform specific way, it should not be hard coded into struct
<beneroth> and the documentation might need an update if the wording is so confusing.
<beneroth> yes
<Regenaxer> thats why I asked
<Regenaxer> which part of the doc is wrong
<Regenaxer> I can't find any
<beneroth> well you are technically right and they are technically right as long as you parse the same sentence has having a different semantic :)
<Regenaxer> Well, the point is that struct cannot do it even if we want
<beneroth> we must talk about the semantic. or about the wording needing to be in a way that it's less easy to interpret it so differently.
<Regenaxer> pil21 does not know the platform
<Regenaxer> This should be a PilCon issue
<beneroth> yes. I think Cesar saw that, and wants to control it via an additional parameter to struct. This is not picolispy, I find.
<Regenaxer> T
<Regenaxer> So I put the platform stuff into @lib/sysdefs
<Regenaxer> created by a C compiler on the platform
<Regenaxer> Now your mail arrives :)
<beneroth> well when (struct) is usable not only for C FFI but all kinds of binary formats, then there is really no point of dealing with platform on same layer, must be higher level. specific to platform, specific to the binary format.
<Regenaxer> Exactly
<beneroth> my mail is not arriving here
<Regenaxer> reading
<Regenaxer> very good to the point!
<Regenaxer> Let's wait for reactions, I answer tomorrow perhaps
<beneroth> thanks. I was not sure if I'm not out of my waters.
<beneroth> yeah no stress
<Regenaxer> no, sounds to the point
<beneroth> they bring good input
<Regenaxer> T
<beneroth> ah now it arrived here too :)
<Regenaxer> Perhaps tankf33der and aw- should jump in too, they are experienced native users
aw- has joined #picolisp
<beneroth> perfect
<beneroth> welcome aw-
<beneroth> <Regenaxer> Perhaps tankf33der and aw- should jump in too, they are experienced native users
<Regenaxer> ah :)
<Regenaxer> aw- has the 6th sense
<beneroth> or good surveillance of the archive :D
<Regenaxer> T, early in the morning
<Regenaxer> 6 o'clock
<beneroth> Regenaxer, so you could use (rd 128) (whatever number) and put then the result into (struct ...) to turn the blob into a picolisp structure?
* beneroth showing his ignorance of 'struct
<Regenaxer> yes, but it supports currently only max 8 byte numbers
<Regenaxer> no bignum directly
<Regenaxer> (rd 1) and then (byte ..) is easier
<Regenaxer> no need for struct perhaps
<beneroth> so a C struct larger than 64bit would give problems?
<Regenaxer> no
<Regenaxer> only this (cnt . size) syntax
<beneroth> ah ok
<Regenaxer> (1 . 4) as Jason used for an "int"
<beneroth> well to be fair
<beneroth> # Store two integers, three doubles, one long, and four characters
<beneroth> is in the example
<beneroth> and yes, that is the effect
<beneroth> but of course the code does not relate to int or double or char
<Regenaxer> yes, for a special C case
<beneroth> (not directly)
<beneroth> T
<Regenaxer> we can create a given C struct
<Regenaxer> if we kniow that something must be aligned
<Regenaxer> we need to put padding bytes
<Regenaxer> this is not automatically
<Regenaxer> and struct does not even know
<Regenaxer> So this is just one example
<Regenaxer> the reference talkes only of byte fields
<Regenaxer> "a pair (num . cnt) where 'num' is stored in a field of 'cnt' bytes"
<Regenaxer> this is the relevant ref
<beneroth> well the use case I had with a binary network protocol could actually not be parsed with (byte), because it consisted of segments smaller than 1 byte. which I needed to shift around into single byte values first, then I could turn them into picolisp numbers or symbols
<beneroth> so (rd) and quite some (<<) and (&) was needed
<Regenaxer> yes, manipulate numbers
<Regenaxer> then store as needed
<beneroth> T
<Regenaxer> fully under your control
<beneroth> yes, needed.
<beneroth> programming languages are just syntax sugar for ASM, in a way. :P
<Regenaxer> right
<Regenaxer> In a real app, 'native' always needs glue code
<Regenaxer> see rcsim
<Regenaxer> or @lib/openGl.l
<Regenaxer> Also what Hunar does now
<Regenaxer> I think aw- did a lot of such stuff
<beneroth> nothing wrong with making the development of this glue code quicker and easier. but never remove control and go with assumptions.
<Regenaxer> yep
<beneroth> T
<Regenaxer> ok
<Regenaxer> I'm tired :)
<Regenaxer> Let's look forward for tomorrow
<beneroth> not questioning assumptions enough is the core problem of both programming and software project management.
<beneroth> yeah
<beneroth> good night :)
<beneroth> thanks for the chat :)
<Regenaxer> Thank you too!
<Regenaxer> and really lets plan this for PilCon
<Regenaxer> good night! :)
<beneroth> yeah, you should ask them if they could participate on a regular pilCon, or if it needs a specially scheduled one :=
<beneroth> :)
<beneroth> good night
cranium has quit [Quit: Leaving]
<aw-> hi beneroth Regenaxer
<aw-> sorry i just woke up ;) 7:25am here
<aw-> i missed the discussion
razzy has quit [Ping timeout: 252 seconds]
<beneroth> no problem aw-
<beneroth> check the ML, the good stuff is there, here we just had a smalltalk
razzy has joined #picolisp
<beneroth> have a good day!
<beneroth> bbl
<aw-> hmmm ok I read the mailing list about native and struct.
<aw-> i think I won't add a comment, except that I don't want struct to modify incoming bytes at all
<aw-> if it starts adding padding for alignment it's just holding hands more than we need and could lead to strange bugs and other unexpected issues.
<aw-> just make it align structures to 1 byte ;)
<aw-> useless discussion IMHO
<aw-> good night beneroth
razzy has quit [Ping timeout: 252 seconds]
razzy has joined #picolisp