ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
<beneroth> makes sense. nice idea with the additional linking!
<beneroth> I hadn't much need for native yet, that is the only reason I didn't do much with it. (CLI wrapping I use a lot, but usually it's not relevant for performance, so no need to go FFI)
<aw-> you could theoretically link with epoll as well, and then create event-based I/O code as well:
<beneroth> wonderful idea!
<aw-> native is not so easy to wrap your head around until you've actually used it
<beneroth> T
<aw-> also hey beneroth working late again? ;)
<beneroth> I'm not sure if you need epoll, can't you work the (task) mechanism for that?
<beneroth> s/work/use
<beneroth> aw-, yeah ^^'
<aw-> beneroth: epoll is a totally different approach
<beneroth> I'm kinda in the last third of rewriting my stack (new iteration)
<aw-> i see
<aw-> it's morning here, will have breakfast now :)
<aw-> g'nite
<beneroth> have a nice breakfast and a good day!
<tankf33der> Nistur: you should take a look to my pil21 test suit, it has a lot combinations and will show ideas how to create sandbox and experiment.
orivej has joined #picolisp
_whitelogger has joined #picolisp
orivej has quit [Ping timeout: 264 seconds]
stultulo has joined #picolisp
f8l has quit [Ping timeout: 264 seconds]
stultulo is now known as f8l
_whitelogger has joined #picolisp
_whitelogger has joined #picolisp
freemint has joined #picolisp
freemint has quit [Ping timeout: 256 seconds]
freemint has joined #picolisp
freemint has quit [Ping timeout: 260 seconds]
freemint has joined #picolisp
orivej has joined #picolisp
<beneroth> Regenaxer, I like to call a method on This, but not the method from the current class but the (super) from the parent class, how to do? just ((method ..) This ...) ?
<beneroth> so like (super), but the caller being another method on This, not the message we want to super
<beneroth> or is the only way to handle the argument specially in the called method (invoking super) ?
<beneroth> hm.. turned out I don't need that
orivej has quit [Ping timeout: 240 seconds]
<beneroth> but still I would like to know... :-)
orivej has joined #picolisp
<beneroth> direct method invocation must be bad because there is no message passing environment, I think
freemint has quit [Quit: Leaving]
<Regenaxer> Hmm, I use (method 'foo2> '+Cls2) sometimes
<Regenaxer> also directly:
<Regenaxer> (dm zuCaption> ()
<Regenaxer> ~(method 'zuCaption> '+lf) )
<beneroth> ah and This is still bound to the current object, therefore it is okay?
<beneroth> (not This changing to '+Cls2 ?)
<Regenaxer> It is just method sharing
<Regenaxer> yes
<Regenaxer> not changing
<Regenaxer> just reuse the code
<beneroth> ok, therefore (super) (extra) etc. can still work :)
<beneroth> yeah nice
<Regenaxer> T
<beneroth> my use case was method A decorating the super method, and method B invoking directly the super method
<beneroth> thanks, I save this as a note :)
<Regenaxer> ok :)
<beneroth> kinda funny I never needed Class-specific method invocation
<beneroth> ~(method 'zuCaption> '+lf) is beautiful :))
<beneroth> code is data :))
<beneroth> Regenaxer, can we be arrogant smugs about other Lisps neglecting List Processing? :P
<Regenaxer> I don't know enough about other Lisps ;)
<beneroth> tztztz, you're caring too less about other languages and programming fashions ;-)
<beneroth> hihi
<Regenaxer> true, very lazy
<beneroth> you get stuff done
<Regenaxer> yeah, it is more efficient for me
<beneroth> merely procrastinating by learning what other people do is lazy (unless one is a journalist, I guess)
<Regenaxer> But it would be wise to look more at other stuff
<beneroth> you look at Knuth, good enough
<beneroth> if you would look at more stuff, you would get confused and your output diluted, I suspect
<beneroth> it's the trap most other fall in
<beneroth> well maybe you wouldn't
<beneroth> but there is only so much time
<beneroth> most programmers don't control the stack their working with. most don't care, even. therefore so many things get redone endlessly and are full of bugs.
<beneroth> hard to control for bugs if you don't control the stack, especially when the stack gets updates every two weeks...
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
orivej has quit [Read error: Connection reset by peer]
orivej has joined #picolisp
<Regenaxer> yes, it is a very nice feeling to be in control
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
<beneroth> I love that everything in PicoLisp is just PicoLisp.
<Regenaxer> :)
<Regenaxer> With pil21 we have a little more dependencies though: libffi and libreadline
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
<beneroth> we get something in exchange
<beneroth> and we're aware of the price, I'd believe
<Regenaxer> yes
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
aw- has quit [Client Quit]
aw- has joined #picolisp
orivej has quit [Ping timeout: 264 seconds]
aw- has quit [Client Quit]
orivej has joined #picolisp
aw- has joined #picolisp
<tankf33der> Regenaxer: hi
<tankf33der> http://ix.io/2rXq
<tankf33der> why this code is ok on pil64 and different on pil21
<tankf33der> ?
<Regenaxer> Hi tankf33der
<Regenaxer> uint8_t b;
<Regenaxer> the first element must be a byte
<Regenaxer> The question is how this struct is aligned
<Regenaxer> it wont use a single byte probably
<Regenaxer> So what is the offset to uint32_t i;
<Regenaxer> depends on the compiler settings
<tankf33der> -123 is a byte
<tankf33der> aligned is: 0 4 8
<tankf33der> last digits of addresses ^^^^
<tankf33der> without pads.
<Regenaxer> A byte is a positive number, no?
<tankf33der> -123 is positive number
<tankf33der> :)
<tankf33der> o no
<tankf33der> wait
<Regenaxer> yes, but 4 bytes, so it works only if little endian
<Regenaxer> if it is 0 4 8 offsets
<Regenaxer> better use 123 0 0 0 for 4 bytes
<Regenaxer> or 0 0 0 123 if the byte is aligned at the end of that field
<Regenaxer> C in general expands chars to ints when passed to functions
<Regenaxer> all highly depending on the compiler
<Regenaxer> and perhaps compiler options
<tankf33der> but results are different betweet pil21 and pil64
<Regenaxer> Is it the same lib?
<Regenaxer> same build I mean
<tankf33der> of course
<Regenaxer> ok, then pil21 and pil64 should be the same
<Regenaxer> What difference?
<Regenaxer> Why do you print without spaces? :) "%d%d%ju",
<Regenaxer> What if you declare 'b' as uint32_t in the struct?
orivej has quit [Ping timeout: 265 seconds]
<tankf33der> afk.
<tankf33der> always diffrent
<tankf33der> What if you declare 'b' as uint32_t in the struct?
<tankf33der> ^^ again pil64 is ok, pil21 wrong or garbage.
<Regenaxer> *All* numbers are different?
<Regenaxer> all three?
<tankf33der> (struct P 'P -123 -1234567 (1234567890123456789 . 8))
<tankf33der> (native "./native.so" "arg1" 'S P) )
<tankf33der> "12312345671234567890123456789"
<tankf33der> (println
<tankf33der> uint32 uint32 uint64
<tankf33der> pil64 ok, pil21 different
<Regenaxer> 'P' is not supported in pil64 btw
<tankf33der> it eats 'P anyway.
<tankf33der> :)
<Regenaxer> not checked
<Regenaxer> same as NIL perhaps?
<Regenaxer> anyway, ok
<Regenaxer> what is "j" for printf?
<Regenaxer> does the buffer 'r' contain the right things?
<Regenaxer> ie. which part goes wrong?
<Regenaxer> sending or reveiving?
<tankf33der> under investigation
<Regenaxer> receiving is just a string, so probably ok
<Regenaxer> Probably it helps if you look with gdb what it does
<tankf33der> its the easiest combination. without padding.
<tankf33der> frustrating.
<tankf33der> all three uint32_t works on both.
<Regenaxer> strange
<Regenaxer> What might be different?
<tankf33der> all uint64_t works only on pil64.
<Regenaxer> hmm, so uint64_t is the problem?
<tankf33der> unknown, still playing.
<tankf33der> my idea was create all possible struct combinations of byte,int,long and check equal of pil21 vs. pil64.
<Regenaxer> good idea
<tankf33der> all uint8_t works.
<tankf33der> all uint8_t works on both.
<Regenaxer> again: What is the "j" format?
<Regenaxer> why not "l" ?
<tankf33der> lint blamed
<tankf33der> %ju - uint64_t
<tankf33der> %jd - int64_t
<tankf33der> in C99
<Regenaxer> I never saw j
<Regenaxer> %ld or %lu
<tankf33der> trying
<Regenaxer> or %lX I use most
<Regenaxer> for debugging
<tankf33der> %lu the same
<tankf33der> pil21 wrong, pil64 as expected.
<tankf33der> [mpech@lambda pil21-tests]$ pil native.l
<tankf33der> native-OK
<tankf33der> "1231234567139691180892080"
<tankf33der> "12312345671234567890123456789"
<tankf33der> : [mpech@lambda pil21-tests]$ pil21 native.l
<tankf33der> native-OK
<tankf33der> :
<tankf33der> [mpech@lambda pil21-tests]$
<tankf33der> so, i see the last uint64_t is always wrong.
<Regenaxer> I check
<Regenaxer> Which part? filling 'r' from the args?
<Regenaxer> s->b, s->i, and s->l are correct?
<Regenaxer> Where exactly does it go wrong?
<Regenaxer> Do you do printf's in C to track all states?
<tankf33der> correct questions. i do my best.
<Regenaxer> There must be exactly one point where it goes wrong in pil21
<tankf33der> yea.
<Regenaxer> yes, I know
<Regenaxer> you are hunting :)
<Regenaxer> I suspect it is the *reading* from the buffer into the result list
<Regenaxer> it is the complicated part
<Regenaxer> 'natRet' in src/main.l
<Regenaxer> ((and (pair Spec) Val) # Arrary or structure
<tankf33der> all uint32_t correct in both.
<Regenaxer> check the case with 64 bit numbers, where it goes wrong
<Regenaxer> eg
<Regenaxer> static char r[BUFSIZ];
<Regenaxer> fprintf(stderr, "%ld %ld %ld\n", s->b, s->i, s->l);
<Regenaxer> sprintf(r, "%d%d%ju", s->b, s->i, s->l);
<Regenaxer> to see if the numbers arrive correctly
<Regenaxer> if so, natBuf must be wrong
<tankf33der> checking.
<Regenaxer> I try similar
<Regenaxer> fill the buffer manually:
<Regenaxer> (setq P (native "@" "malloc" 'N 32))
<Regenaxer> (for (I . B) (1 2 3 4 5 4 7 8 1 2 3 4 5 4 7 8 1 2 3 4 5 4 7 8)
<Regenaxer> (byte (+ P I -1) B) )
<Regenaxer> the read with struct
<tankf33der> yea.
<tankf33der> show me struct you work with ?
<tankf33der> we must synced
<Regenaxer> I try
<Regenaxer> correct
<Regenaxer> (setq P (native "@" "malloc" 'N 32))
<Regenaxer> (for (I . B) (1 2 3 4 5 4 7 8 1 2 3 4 5 4 7 8 1 2 3 4 5 4 7 8)
<Regenaxer> (byte (+ P I -1) B) )
<Regenaxer> (msg (struct P '(N N N)))
<Regenaxer> gives
<Regenaxer> (578435496729051649 578435496729051649 578435496729051649)
<Regenaxer> this is correct
<Regenaxer> (hex 578435496729051649)
<Regenaxer> -> "807040504030201"
<Regenaxer> So *reading* the struct works?
<Regenaxer> 1 2 3 ... in little endian
<Regenaxer> Where else might it go wrong?
<tankf33der> http://ix.io/2rXZ
<tankf33der> read this
<Regenaxer> the printf shows that the written data are wrong
<tankf33der> yea, in pil21
<tankf33der> only on pil21
<Regenaxer> I try directly
<Regenaxer> example is too involved
<tankf33der> (msg (struct P '(N N N)))
<tankf33der> this one is working
<tankf33der> as i tried before.
<tankf33der> try B I N
<tankf33der> when all three are equal, it works in any combinations.
<Regenaxer> hmm, this works too:
<Regenaxer> (setq P (native "@" "malloc" 'N 32))
<Regenaxer> (msg (struct P '(N N N) (123456789 . 8) (123456789 . 8) (123456789 . 8)))
<Regenaxer> so writing is also OK
<tankf33der> you should check when not all three are equal.
<tankf33der> use any first and last N
<tankf33der> let me try if two and last in N
<Regenaxer> works too
<Regenaxer> (setq P (native "@" "malloc" 'N 32))
<Regenaxer> (msg (struct P '(N N N) (123456789 . 8) (123456789 . 8) (123456789 . 8)))
<Regenaxer> -> (123456789 1234567 123456789)
<Regenaxer> for (struct P '(N I N) (123456789 . 8) (1234567 . 4) (123456789 . 8))
<Regenaxer> So structure access is correct
<Regenaxer> It must be the C lib
<tankf33der> two is wrong too if last is N
<Regenaxer> Which two?
<tankf33der> uint32 and uint64
<tankf33der> [mpech@lambda pil21-tests]$ pil native.l
<tankf33der> "1231234567890123456789"
<tankf33der> 123 139917231304624
<tankf33der> : [mpech@lambda pil21-tests]$ pil21 native.l
<tankf33der> 123 1234567890123456789
<tankf33der> native-OK
<tankf33der> "123139917231304624"
<tankf33der> native-OK
<tankf33der> :
<Regenaxer> I want to try without C lib in between
<Regenaxer> Like this? (struct P '(N I N) (123 . 4) (123 . 4) (123 . 8))
<Regenaxer> ah!
<Regenaxer> this gives -> (528280977531 123 0)
<Regenaxer> oops
<Regenaxer> must be of course
<Regenaxer> (struct P '(I I N) (123 . 4) (123 . 4) (123 . 8))
<Regenaxer> yes
<Regenaxer> gives -> (123 123 123)
<Regenaxer> So all correct?
<Regenaxer> The C program does too much
<tankf33der> hm.
<Regenaxer> we must get to the point
<Regenaxer> isolate the part which goes wrong
<Regenaxer> Can you paste a simple example where pil21 goes wrong?
<Regenaxer> Ignore pil64
<Regenaxer> just pil21
<Regenaxer> then print intermediate values
<Regenaxer> to see *where* it goes wrong
<Regenaxer> either when writing to the buffer
<Regenaxer> or when reading it
<Regenaxer> best print the contents of the buffer as bytes
<Regenaxer> in a for(;;) loop
<Regenaxer> not uintXX values
<Regenaxer> we don't know how C alignes them
<tankf33der> i can check aling in stderr
<Regenaxer> yes
<Regenaxer> for (char *p = r, i = 0; i < 24; ++i) printf("%x ", *p++;
<Regenaxer> best to clear the buffer first
<Regenaxer> with memset
<Regenaxer> all zeroes
<Regenaxer> then store the values and print the hex bytes
<Regenaxer> so we see what C does with the values
<Regenaxer> There may be garbage bytes in between
<tankf33der> http://ix.io/2rY3
<Regenaxer> ah, it is a string! I forgot
<Regenaxer> can you paste all code again?
<tankf33der> http://ix.io/2rY4
<Regenaxer> So this is already wrong? 1234567,139945236610992
<tankf33der> yea
<tankf33der> always
<tankf33der> 1234567,1234567890123456789
<Regenaxer> so s->u64 is wrong?
<Regenaxer> can you print it?
<Regenaxer> printf("%lu\n", s->u64);
<tankf33der> fprintf(stderr, "%d,%lu\n", s->u32, s->u64);
<tankf33der> fprintf(stderr, "%p,%p\n", &s->u32, &s->u64);
<tankf33der> already
<tankf33der> see the link
<Regenaxer> you print the addresses
<Regenaxer> I wonder if the value arrives correctly
<tankf33der> 16:05 <tankf33der> fprintf(stderr, "%d,%lu\n", s->u32, s->u64);
<tankf33der> this one prints addresses ?
<Regenaxer> sorry, yes
<Regenaxer> &s->u64); is address
<Regenaxer> s->u64); is correct
<tankf33der> so i got wrong value in function.
<Regenaxer> cause it is padded?
<Regenaxer> (1234567 . 4) (0 . 4) ?
<tankf33der> yea, manual padding
<tankf33der> because fprintf(stderr, "%p,%p\n", &s->u32, &s->u64);
<Regenaxer> this puts the next long in the wrong place
<tankf33der> prints 0 and 8 at the end.
<Regenaxer> struct arg1s {
<Regenaxer> uint32_t u32;
<Regenaxer> uint64_t u64;
<Regenaxer> };
<Regenaxer> 4 bytes plus 8 bytes
<tankf33der> no
<tankf33der> 4 bytes, 4 bytes padding, 8 bytes
<Regenaxer> cause of alignment?
<tankf33der> in this case.
<tankf33der> 0x55699ea15040,0x55699ea15048
<tankf33der> ^^^ fprintf(stderr, "%p,%p\n", &s->u32, &s->u64);
<tankf33der> in this case yes.
<Regenaxer> Sorry, the bytes in 'r' are not needed
<Regenaxer> the struct must be dumped
<Regenaxer> it has the wrong values
<Regenaxer> (struct P 'N (1234567 . 4) (0 . 4) (1234567 ...
<Regenaxer> does not match
<Regenaxer> somehow
<tankf33der> but ok in pil64
<Regenaxer> How do you know (0 . 4) is needed?
<tankf33der> because i manually align first field and insert additional 4 bytes
<tankf33der> to it
<Regenaxer> the problem is between (struct P 'N ( ...) and fprintf(stderr, "%d,%lu\n", s->u32, s->u64);
<Regenaxer> what you tell struct and what C believes of the struct does not match
<Regenaxer> yes, &s->u32, &s->u64 is 8 bytes
<tankf33der> all above ok in pil64.
<Regenaxer> is u32 right aligned in the buf?
<Regenaxer> Forget pil64
<Regenaxer> debug pil21
<Regenaxer> Locate exactly the place where it goes wrong
<tankf33der> i cant.
<Regenaxer> Fact is that the first place is wrong already
<Regenaxer> 1234567,139945236610992
<Regenaxer> ok
<Regenaxer> try (struct P 'N (`(hex "12345678") . 4) (0 . 4) (`(hex "1234567812345678" . 8)))
<Regenaxer> then hexdump the struct
<tankf33der> hexdump ?
<Regenaxer> for (char *p = (char*)&s ...
<Regenaxer> not 'r'
<Regenaxer> we must see what arrives in the struct
<Regenaxer> No need to print the other stuff
<Regenaxer> cause we know that s->u64 is wrong
<Regenaxer> So I want to know what is in the struct
<Regenaxer> to see if (struct P 'N ...) creates the wrong data
<Regenaxer> it must be 12345678000000001234567812345678
<Regenaxer> the for loop over 32 bytes
<Regenaxer> no
<Regenaxer> 16
<Regenaxer> I don't understand, cause
<Regenaxer> (struct P '(I I N) (123 . 4) (0 . 4) (123 . 8))
<Regenaxer> gives correct result
<Regenaxer> -> (123 0 123)
<Regenaxer> or is *both* write and read wrong with the same offset?
<tankf33der> trying.
<Regenaxer> thx
<tankf33der> http://ix.io/2rY8
<tankf33der> what i see.
<Regenaxer> Was interrupted
<Regenaxer> is "40 ffffffd0 ffffffd3 64 2c 56..." the output?
<Regenaxer> can't be
<tankf33der> code above.
<tankf33der> #(struct P 'N (1234567 . 4) (0 . 4) (1234567890123456789 . 8))
<tankf33der> (struct P 'N (`(hex "1234567") . 4) (0 . 4) (`(hex "1234567812345678") . 8))
<Regenaxer> yes, no spaces
<Regenaxer> between the bytes
<tankf33der> which one to use on picolisp side ?
<Regenaxer> yes, Pil side is good
<Regenaxer> (`(hex "1234567") . 4) (0 . 4) ...
<tankf33der> the i should post new output.
<Regenaxer> ah, ok
<Regenaxer> the bytes are signed
<Regenaxer> no
<Regenaxer> could be (unsigned char*)
<Regenaxer> but does not matter
<Regenaxer> still the bytes are nonsense
<Regenaxer> moment, interrupt
<Regenaxer> should be 78 56 34 ... for little endian, no?
<tankf33der> $ pil21 native.l
<tankf33der> 0x55b5e7141040,0x55b5e7141048
<tankf33der> 19088743,140376140649616
<tankf33der> "19088743,140376140649616"
<tankf33der> :
<tankf33der> 40 10 14 ffffffe7 ffffffb5 55 0 0 40 16 3c 5c fffffffe 7f 0 f :
<tankf33der> native-OK
<tankf33der> with new picolisp side.
<Regenaxer> 40 10 14 is complete nonsense
<Regenaxer> hmm, you filled other numbers
<Regenaxer> not (hex "1234567812345678")
<Regenaxer> I want the above hex numbers
<Regenaxer> to see the bytes
<tankf33der> (hex "1234567") is first part of output:
<tankf33der> 19088743,139751040578704
<Regenaxer> I want to see the 16 bytes in the struct
<Regenaxer> not decimal numbers
<Regenaxer> try (struct P 'N (`(hex "12345678") . 4) (0 . 4) (`(hex "1234567812345678" . 8)))
<Regenaxer> then the dump must be
<Regenaxer> 78 56 34 ...
<Regenaxer> then 00 00 00 00
<Regenaxer> then the long
<Regenaxer> or 0 0 0 0 without padding
<tankf33der> ir coredumps.
<tankf33der> it coredumps.
<Regenaxer> I cannot compile here now. Perhaps in one hour
<tankf33der> the same nonsense.
<tankf33der> let me try call from C and hexdump.
orivej has joined #picolisp
<Regenaxer> I try later
<Regenaxer> this is too difficult to do in irc :)
<tankf33der> $ gcc native.c && ./a.out
<tankf33der> 1234567,1234567890123456789
<tankf33der> 20 ffffffbf 73 ffffffbc fffffffc 7f 0 0 27 ffffffbf 73 ffffffbc fffffffc 7f 0 f 1234567,1234567890123456789
<tankf33der> 0x7ffcbc73bf20,0x7ffcbc73bf28
<Regenaxer> I would do gcc -o x.so -shared x.c
<Regenaxer> let me try now
<Regenaxer> I'm helping my wife though
<Regenaxer> can't fully concentrate
<tankf33der> its ok
<Regenaxer> Preparing Sushi course
<tankf33der> i am on vacation.
<Regenaxer> yeah, I know :)
<tankf33der> lets take a break.
<Regenaxer> ok
<tankf33der> ping me later.
<Regenaxer> but it nags me :)
<Regenaxer> yes
<Regenaxer> ok
<Regenaxer> Ah, my fault! The pointer is wrong
<Regenaxer> This works: http://ix.io/2rYh
<Regenaxer> not &s !!
<Regenaxer> s *is* a pointer
<Regenaxer> sorry!
<Regenaxer> now I get:
<Regenaxer> 78 56 34 12 0 0 0 0 d0 33 a5 8f 7e 0 0 0
<Regenaxer> so the long is bad
<Regenaxer> BUT!
<Regenaxer> (`(hex "12345678123456") . 8) works
<Regenaxer> 78 56 34 12 0 0 0 0 56 34 12 78 56 34 12 0
<Regenaxer> So I know the problem is with bignums
<Regenaxer> "12345678123456" still fits into a short
<Regenaxer> and thus works
<Regenaxer> the test is http://ix.io/2rYi
<Regenaxer> Now I check 'natRet' what goes wrong with the number
<Regenaxer> not natRet
<Regenaxer> natBuf
<tankf33der> sounds good
<Regenaxer> :)
<Regenaxer> getting close
<Regenaxer> (T (set (i64* Ptr) X)
orivej has quit [Ping timeout: 258 seconds]
<Regenaxer> found it
orivej has joined #picolisp
<Regenaxer> (dig X) must be (val (dig X))
<Regenaxer> I use the pointer instead of the value
<Regenaxer> also in another place, fix it
<Regenaxer> I better check all sources
<Regenaxer> oops, one more such case in 'pathSize'
<Regenaxer> Hard to detect
<Regenaxer> cause numbers up to 60 bits work
<Regenaxer> Works now
<Regenaxer> Released!
orivej_ has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
<tankf33der> i will play.
<Regenaxer> :)
<Regenaxer> I will continue with io.l later
<Regenaxer> perhaps finish this weekend
<Regenaxer> Now on a walk
orivej has joined #picolisp
<tankf33der> yea, works and nothing is broken.
orivej_ has quit [Ping timeout: 258 seconds]
<Regenaxer> cool
<beneroth> coooool
<Regenaxer> I think we should move src/net.l out of the base system
<Regenaxer> -> lib/net.l
<Regenaxer> and use 'native'
<Regenaxer> More flexible, and not time critical
<Regenaxer> pil21 will also have a 'buffer' function
<Regenaxer> to allocate directly on the stack
<Regenaxer> Less need for 'malloc'
<tankf33der> afk.
jibanes has quit [Ping timeout: 264 seconds]
jibanes has joined #picolisp
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #picolisp
orivej has quit [Read error: Connection reset by peer]
f8l has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
f8l has joined #picolisp
orivej_ has joined #picolisp
orivej has quit [Read error: Connection reset by peer]
jibanes has quit [Ping timeout: 240 seconds]
jibanes has joined #picolisp
orivej_ has quit [Ping timeout: 246 seconds]
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
<tankf33der> implemented combinations with and without padding, works. perfect test for both native and struct.
<tankf33der> afk.
<Regenaxer> great
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #picolisp
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
orivej has quit [Read error: Connection reset by peer]
orivej_ has joined #picolisp
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
orivej_ has joined #picolisp
orivej has quit [Read error: Connection reset by peer]
orivej_ has quit [Read error: Connection reset by peer]
orivej has joined #picolisp
orivej has quit [Ping timeout: 258 seconds]
orivej_ has joined #picolisp
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
alexshendi has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
<beneroth> one for freemint: https://xkcd.com/2323/