<ArneBab>wingo: with 2.1.7 I have a loop where this ends with #t: (while (not (eof-object? nextchar)) <ArneBab> (write (eof-object? nextchar)) ...) <ArneBab>how can (while (not (eof-object? x)) (write (eof-object? x))) ever give #t? <davexunit>hoo boy am I sick of seeing david kastrup emails in my inbox. I need to add a filter or something. <ArneBab>davexunit: I wish we could fix the problems - social and technical :( <holomorph>i meant to figure out how to do that in gnus, but… gnus :c <nalaginrut>davexunit: I choose to be friendly tough to speak to him if he always doesn't know on which planet he's standing ***Shozan is now known as SHODAN
<civodul>in statprof in 2.2, i have something like this: <civodul> 90.97 3.22 2.82 anon #x7f1b6141ed00 <civodul>could it be the lambda of with-statprof? <wingo>civodul: it is a bug i need to fix in statprof <wingo>however to dig in for now, do ,profile foo #:display-style tree <wingo>if you pass #:display-style to the statprof command, then 'tree (with quote) <wingo>someone should rewrite quicksort in scheme to see if it is faster <wingo>doing that would avoid a number of c<->vm transitions, so it's possible <ArneBab_>wingo: I’m pretty sure that the code I pastebinned you exposes a compiler bug, but I don’t manage to create a minimal working example. <wingo>ArneBab_: can you send to guile-devel or bug-guile? <ArneBab_>(too keep the train of thought: if you insert a (newline) after line 323, the code works) <wingo>i guess you tested on 2.0 as well? <wingo>ah this is nice, i like it when there are new commits on master not by me :) <civodul>it's weird, guix seems to be gc'ing more with 2.2 than with 2.0 <civodul>but gcprof shows a flat profile with only 0.00 <wingo>i have a fix to land for gcprof tooo <wingo>should i take another look at bytevector->string from iconv? <wingo>i'm pretty sure the code as-is performs well for smaller files but not larger ones <wingo>for larger ones it will end up creating a list of characters millions of elements long, which is hard on gc to trace <civodul>i have Guix running on 2.2, and performance seems to be slightly less good than with 2.0, but it's kinda hard to profile <civodul>and of course it does a lot of i/o and gc, so it could be anything <wingo>i don't like that perf is less good :) <wingo>must be something port-related i guess <wingo>anyway i will fix this read-string thign <wingo>yeah, and add a string-set! thing to the vm; otherwise it's hard to do efficient textual i/o in scheme <wingo>most efficient operations work in batches, and to work on characters in batches you need a buffer, and a string is a buffer of characters... so you need decent string-set! support. <HiPhish>wingo: I think I found another bug. The body of the method (define-method (- (v <vector3>)) (* -1 v)) gets rewritten to (- 0 v), which doesn't make sense because you cannot subtract a vector from a scalar. <HiPhish>Typing explicitly (* -1 v) in the REPL works fine. <wingo>HiPhish: did you see the recent list discussion about this? (were you the one that reported that one?) <wingo>ACTION forgets what status all the bugs are in :) <HiPhish>wingo: I reported that (* -1 v) was causing problems, but I don't recall reporting (- v). <wingo>would you mind sending a mail with the problem report to bug-guile@gnu.org? no subscription necessary <HiPhish>wingo: Sure thing, I just wanted to make sure this was really a bug and not me being stupid :) <wingo>it sounds like a bug but i will need to look into it :) <HiPhish>On an unrelated note, how do I load a file relative to the current working directory? I tried ',load derp.scm', but that one looks for the path relative to the system directory. <wingo>hmm, i never use ,load, i don't remember what it does :) <wingo>use the scheme procedure instead of the repl command i guess <HiPhish>wingo: Thanks, that's good enough for me. I'm thinking about making a poor-man's REPL for Neovim by wrapping the terminal emulator with some custom commands and keybindings. I won't be pretty, but a quick&dirty hack will be better than nothing. <wingo>?? somehow my backwards loops are being compiled to full backwards tail calls <wingo>maybe only within case-lambda functions? strange <wingo>i wonder how long that's been the case :) <lloda>bug in master, must be recent <lloda>scheme@(guile-user)> (= -1. (make-rectangular -1.0 0.0)) <lloda><unnamed port>:1:0: <unnamed port>:1:0: Wrong type (expecting real number): -1.0+0.0i <lloda>works with guile -c '(display (= -1. (make-rectangular -1.0 0.0)))', it's only the repl :-/ <wingo>lloda: only the compiler i think <wingo>i guess it's only =, right? i mean < <= >= > should all error when comparing real and complex <lloda>btw (= -1 (make-rectangular -1.0 0.0)) does work <wingo>or maybe given this goops thing, we should avoid specializing if one of the operands isn't real <wingo>yeah i think this is fallout from the unboxed float comparisons thing <wingo>ACTION hopes davexunit is following along, just to know what sorts of errors are possible in this part of the code :) <lloda>guessing the bug is in ((or (f64-operand? a) (f64-operand? b)) ...) in language/cps/specialize-numbers.scm (?) <wingo>i think it should require that both operands are reals <lloda>u64 has another case u64-scm, doesn't that make sense here? <roelj>Is the ^ character special in a format string? <lloda>roelj: not on its own afaiu, but there's a command ~^ <wingo>lloda: no, (f64-operand? a) means that not only is a real, it is inexact <lloda>would this work then (and (real? a) (real? b) (or (f64-operand? a) (f64-operand? b))) ? <wingo>because "a" is a CPS variable, not a value <wingo>you do: (and (or (f64-operand? a) (f64-operand? b)) X) <wingo>note the definition of f64-operand? -- <wingo>(let-values (((type min max) (lookup-pre-type var))) (eqv? type &flonum)) <wingo>what you need is an assertion that a and b are both reals <wingo>so what you do is (zero? (logand (logior type-a type-b) (lognot &real))) <wingo>note that &real is (logior &exact-integer &flonum &fraction) <wingo>(to figure out what you need for X, i mean) <davexunit>you can just revert the floating point ops thing <wingo>np, it is an easy fix, just thought you would be interested <wingo>ACTION pleased at fixing this contificatoin thing <wingo>davexunit: np, i've made many bugs in this area before :P <wingo>guile can now contify (letrec ((foo ...)) (case-lambda (() (foo ...)) ((a) (foo a ...)))) <wingo>scheme@(guile-user)> (define f (let () (define (lp) (lp)) (case-lambda (() (lp)) ((_) (lp))))) <wingo>Disassembly of #<procedure 22395b8 at <unknown port>:6:37 () | (_)> at #x22394c0: <wingo> 0 (br-if-nargs-ne 1 4) ;; -> L1 at (unknown file):6:37 <wingo> 2 (alloc-frame 2) ;; 2 slots <wingo> 4 (assert-nargs-ee/locals 2 0) ;; 2 slots (1 arg) <wingo> 5 (handle-interrupts) at (unknown file):6:65 <wingo>note the bit at 3 where it jumps from the first clause into the second one <wingo>(the second clause starts at L1) <davexunit>I wonder if there's any "real world" code out there that will benefit from this <wingo>code that uses case-lambda for optional arguments <wingo>often that kind of code will use the case-lambda as a dispatch then call a common helper that does the work <wingo>or if it recurses instead, that recursion could be contified also into a jump to the other clause <davexunit>in that case the helper can't be a top-level procedure, is that correct? <wingo>currently no, but that's the top-level inlining discussion <wingo>civodul: ok i have a read-string on a 80M file that completes now in 8s instead of 80s <davexunit>wingo: yeah I was just making sure that I was understanding that correctly. <davexunit>so that I can do the right thing when writing case-lambas in the future <wingo>well first i had to fix that contificatoin bug; read-string is a case-lambda and because of that, nothing was contifying <wingo>ooh cool, guile 2.0 takes 12.5s on this <wingo>the next thing was just to use a geometrically growing series of string buffers with string-set! instead of cons <wingo>civodul: no, guile 2.0 takes 12.5s with the impl in C; my local guile 2.2 takes 8s with the impl in scheme <wingo>whereas guile 2.2 in master takes 80s on that file <wingo>just gotta check now that it works ok for short strings... <civodul>ports.bm has a simple micro-benchmark for 'read-string' <wingo>yes i think i used those at one point <wingo>i guess they are better for short strings, i don't think they test 80M strings <wingo>which is where this strategy ran into problems <wingo>ok by decreasing the initial buffer size from 100 to 30 i still have good perf for reading smaller strings; as good as 2.0 anyway <civodul>why would it be slower than 2.0 anyway? <wingo>because 2.0 uses a stack-allocated buffer for small strings <wingo>and can truncate strings in place <wingo>lloda: yes, that looks great! <wingo>civodul: no i think read-string uses rdelim somehow in 2.0, no? <civodul>no, it's that tight loop that conses chars <wingo>that is something worth looking into <wingo>ACTION does a git stash then <lloda>wingo: pushed, thanks for the help <wingo>thank you for finding and fixing it! <lloda>it's easy to care about bugs that affect you ;p <civodul>on 2.0: "ports.bm: rdelim: read-string" 200 real 3.003439846 <civodul>on 2.2: "ports.bm: rdelim: read-string" 200 real 2.524153546 <civodul>so 2.2 is better, for 100KiB strings at least <wingo>right i think i used those tests when checking for regressions <wingo>i think there is a size for which 2.2 starts not being good; spending lots of time in GC or something <wingo>at least with my local tests it seemed like that could be it <wingo>you can try yourself, make a file (call-with-output-file "/tmp/foo.txt" (lambda (p) (display (make-string #e80e6 #\\a) p))) <wingo>then ,time (string-length (call-with-input-file "/tmp/foo.txt" read-string)) <civodul>on 2.0: 10.887474s real time, 12.409724s run time. 3.594733s spent in GC. <civodul>on 2.2: 63.618637s real time, 73.229619s run time. 0.013416s spent in GC. <wingo>at least i saw a big gc time <civodul>because it says very little time is spent in GC <civodul>orders of magnitude less than on 2.0, strangely <civodul>do you think the GC time measurements are off? <lloda>the gc times are very variable. Makes benchmarking hard <wingo>i thin kthat the run time is greater than the real time is a clear sign it's gc <civodul>second try: 67.066328s real time, 138.603808s run time. 0.000000s spent in GC. <wingo>for me on 2.2 i get ;; 72.227415s real time, 82.122753s run time. 74.492869s spent in GC. <wingo>so this case is really hard for the gc -- it's a linked list 80M elements long <wingo>yeah i don't know why your gc time is so low <civodul>yes but it should be just as hard with 2.0 and 2.2? <civodul>so it's really GC; ",pr" also shows that we spend less time in the code <civodul>nothing has changed in gc.c (same space divisor for instance) <civodul>could it be ports that cons too much? <wingo>if you are right then we should see similar times in a (let count ((n 0)) (if (eof-object? (read-char)) n (lp (1+ n))) loop <wingo>otherwise it would indicate some other gc-related problem <wingo>which i guess callgrind could help us with <civodul>BTW, regarding GC times, could it be that the after-gc hook doesn't get call the way we think? <civodul>libgc doesn't provide us an after-gc callback <civodul>so AIUI, our after-gc hook is an async <civodul>so if we block asyncs or wait in a syscall or something, we the after-gc hook is called at the wrong time <civodul>or it might also be called too early maybe? <wingo>i don't think it can be called too early <wingo>but yeah, similar things are possible :) <civodul>if there's before-gc hook that contains Scheme code that happens to run asyncs? <wingo>the before-gc hook cannot contain scheme code <wingo>it is only in C and called within the alloc lock <wingo>so what i am seeing is that the read-char loop is faster in 2.2 than 2.0, allocating a similar amount of memory in its execution on this test file (some 340 KB; not sure where all that's coming from, but ok) <wingo>starts from a lower total heap size in 2.2 (4.6M vs 9M) <wingo>2.2 vs 2.0 timing on that loop is 5.8s vs 8.15s <wingo>so i guess i will callgrind the full test <wingo>btw we don't have kcachegrind in guix yet, do we? :) <wingo>ACTION hsa an old script to interpret callgrind output but would like kcachegrind <civodul>wingo: we don't have it, but we should definitely add it! <wingo>iirc they bundled it up with a bunch of other kde things <wingo>fml, at the console guile 2.2 exhibits the 8s time <wingo>well, i know the difference anyway <wingo>(use-modules (ice-9 rdelim)) <wingo>(pk (string-length (call-with-input-file "/tmp/test.txt" read-string))) <wingo>so with that file, already compiled <wingo>if i just pop in a guile 2.0 repl, load it, then do ,stat <wingo>i see that gc has run 18 times, and final heap size is 1390424064 bytes <wingo>in 2.2 i see that gc has run 160 times, 1381588992b heap size <wingo>i guess it has to be something about the scm_gc_register_allocation? dunno <wingo>humm, indeed, it seems the inline allocator code seems to be triggering GC more frequently than the out-of-line code would have done ***dje is now known as xdje
<civodul>i keep discovering goodies in 2.2 :-) <wingo>yeah i don't really understand. it's not the ports code however. also i think that get-string-all on a 80MB file should not take 1.3 GB of heap, regardless of how much time it takes <wingo>so i will look at applying this patch <wingo>if it reduces heap size on a get-string-all <wingo>ok it does reduce heap size by a factor of 10 or so, as you would expect (each char occupying a non-traced byte (in this case) instead of a GC-traced cons) <wingo>civodul: well i "fixed" read-string, then, for big files <wingo>though this weird running-gc-too-often bug still seems to be there <wingo>i checked and it doesn't appear to be related to scm_gc_register_allocation <spk121>Hello. I'm trying to get latest guile master to build, but, I'm getting BOOTSTRAP GUILEC ice-9/eval.go Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind handler. <spk121>Is there a simple fix for increasing stack in the build? <taylan>what do people use when they have a program using srfi-9 records, and they realize they would really like to subtype their record types? I wonder if I should try to implement srfi-99 for guile... <daviid>taylan: in what sence? it is always a surprise to me people would want to subtype classes and not take advantage of generic functions? what is the purpose of subclassing and then have to write diff procedures, instead of methods ... Just curious <taylan>one doesn't have to write different procedures for type and subtype in e.g. srfi-99. the getters and setters that are valid for a type are also valid for its subtype (which is technically "generic functions" I suppose?) <taylan>what you can't do with srfi-99 is call the same procedure on entirely different types and have it dispatch to a method, which is the intent of a proper generic functions system AFAIUI. (and I don't need that functionality, nor any other OOP features other than plain subtyping.) <taylan>but maybe I can just use a small subset of GOOPS functionality and be happy <amz3>goops is too far away from Python for me <amz3>a post about how to use goops from a pythonista perspective would be helpful <taylan>well meh, I think I'll just solve this with some ad-hoc faux-subtyping (additional field in record type for "subtype"-specific payload) since it's a library which has so far been portable across Scheme implementations and I don't want to change too many things... <daviid>taylan: definitely, it will give you some experience as well, usefull for your work for srfi's and then it will make a better programmer (not joking here) <taylan>I don't think I'll really be working on SRFIs anymore; I gave up r7rs-large :\\ <taylan>I'm also generally inactive in software development lately but if I "come back" I'll concentrate on guile instead. <amz3>taylan: out of curiosity, why did you give up on r7rs-large? <daviid>taylan: what library are you refering to here above? <amz3>taylan: did you read on the mailling that Matte Wette is working on an automatic binding library using bytestructures? <taylan>amz3: a few significant disappointments piled up. hash tables (srfi 125), lack of syntax-case support, the general direction of r7rs-large, and record types. the gigantic discussion and multiple strange SRFIs that suddenly sprung out of a question about record types was the last drop. <amz3>I read that record types are a source of troubles in scheme noosphere <taylan>amz3: I didn't hear about Matte Wette's work, no. <taylan>a C parser to autogenerate bytestructure descriptors was on my long-term todo that I never got to work on :) <daviid>taylan: tx. given you will concentrate on guile (as you said above) i'd use goops, given the description of the situation you gave above, it just does not make any sence to write your own 'subtyping adhoc system' <taylan>I think it would be better to prevent overhauling the bytestructures implementation <davexunit>taylan: I get the impression that the main driver of all this scheme standard stuff isn't doing a very good job <amz3>William Byrd, the creator of minikanren doesn't understand that I wrote a clone of Datomic and that it's powered by minikanren <daviid>taylan: goops is not 'overhauling' any of the app/lib that uses it :), you should try it <amz3>ACTION goes answer question on #racket maillingt list <taylan>daviid: I guess it could work as a (quasi) drop-in replacement. (quasi because I'll still need to rewrite code, even if only as a syntactic transformation so to say.) I'd still like to not trash the non-guile support when there's no bigger reason to do so. <taylan>davexunit: to be honest I had major gripes with other people too, not just J. Cowan's choices <amz3>that basically sums up all I already know about goops, now i know it better <taylan>davexunit: from the four things I listed --hash tables, syntax-case, record types, general direction of r7rs-- only the last one (general direction) is in the hands of John. <taylan>the choice between srfi 125 and 126 was democratic, distaste of syntax-case is very widespread, and people were also fairly split over the record type topic, with John barely taking part in the discussion IIRC <davexunit>taylan: ah, interesting. there must be a lot of discussion going on where I can't see it. <davexunit>from my perspective it just seems like jcowan is doing everything without much input <paroneayea>the person leading r7rs-small is the person who wrote Chibi Scheme, irregex, and fmt <paroneayea>and they seem to know what they're doing at least <paroneayea>I skimmed through r7rs-small and thought it looked reasonable. I haven't looked at r7rs-large though <paroneayea>of course, i haven't implemented a full scheme, so I wouldn't know what red flags to look for <daviid>the scheme community should not be so 'close minded' and work on an 'immutable generic function multi-method polimorphic dispatch' (thread safe) oop system, 'à la clos/goops'. this record type/subtype system will always be a 'pale' system compared to, largely inferior and will never solve 'real' problems. then most schemers facing the need for ... ends-up writing 'I will write 'my own adhoc subclass system' <taylan>OrangeShark: yes, and likely will be for the following years... <OrangeShark>I looked though r7rs-small, was even starting to write my own small scheme implementation and there wasn't anything that seemed too bad. <taylan>paroneayea: they're a pretty seasoned Schemer who generally knows what they're doing, but I found them to be needlessly puritan w.r.t. some topics. we had difficulties with Alex on the topic of hash tables and record types, and they don't support syntax-case to say the least (not sure if it would be fair to say they oppose it) <taylan>daviid: actually I think plain srfi-9 record types solve 90% of the problems one faces where one would think of using classes/objects, and subtyping may just be another 9% :P in my ~5 years of professional software development I'm not sure if I ever faced a problem that really required any OOP features other than encapsulation/abstraction (solved by a module system), bundling of data (solved by <taylan>basic structs/records), and subtyping <daviid>taylan: without generic functions and a MOP, I would not even look into it :) but back to hacking now <paroneayea>generic methods can be useful even if you aren't using a MOP <daviid>yes, but the system is only complete if it offers a MOP <daviid>then users can use 1%, or all of it ... <paroneayea>daviid: I'm totally behind the MOP, but! I think it's worth encouraging people who aren't interested in it to still take a look at generic methods <paroneayea>I watched a recent video where Sussman gave a good justification for why he uses generic methods, even though he uses simple type-tagged property lists for his datastructures <amz3>taylan: subtyping is like having the same methods but different fields? <daviid>paroneayea: I totally agree. it's just that the conversation with taylan was about 'scheme' rs*rs should have ... hence what I wrote <paroneayea>I love the MOP, but it's complicated to implement, but great once you have it... plenty of lispers seem turned away by that, but okay. (I think what the MOP gives you for "live hacking" makes it more than worth it though). Generic methods are dead easy to implement, so for those schemers who prefer to cut down what they use to what they perceive as very minimal <paroneayea>daviid: well I kind of agree that probably scheme doesn't need a MOP; if anything, maybe a portable MOP on top of rnrs would help <daviid>paroneayea: then we disagree, but back to hack now <paroneayea>daviid: out of curiosity if you prefer a lisp with a MOP, why don't you prefer common lisp? <daviid>paroneayea: well i use guile, not lisp, and the talk was about 'i will write my own subclass adhoc...' and the expression of my opinion that 'the scheme community should not be so 'close minded' and work on an 'immutable generic function multi-method polimorphic dispatch' (thread safe) oop system, 'à la clos/goops' <paroneayea>I don't agree that it necessarily needs to be part of rnrs <paroneayea>but I think that the nose-thumbing of the MOP is a bit unnecessary, it can be helpful <daviid>paroneayea: I agree with you, being part of guile is enugh for me, but it could be part, it would be better ... <davexunit>personally I just want Guile to be the best it can be, standard scheme seems doomed to being inadequate. <paroneayea>davexunit: I'm afraid you're probably right that standard scheme will never be very standard :) <paroneayea>common lisp succeeded at being reasonably very compatible because it was huge <paroneayea>but most schemers don't seem to want scheme to be huge <paroneayea>I guess r7rs-large maybe is the goal for hugeness but most schemes also seem pretty vested in the interfaces they already have for historical reasons <daviid>paroneayea: unlike you said though, I beleive the MOP is at the very center part of the 'system', I'm talking about design, not users, and design wise, the MOP has to be at the heart, it can't be plug-in later ... without it, it would be an order of magnitude inferior to clos, and I'm talking about a clos based system, but better (actually immutable and thread safe, the rest, we keep it all) <paroneayea>daviid: why do you think it has to be at the heart to be useful in that way? <daviid>paroneayea: it is design problem <paroneayea>daviid: esp if goops gets support for records in generic methods again (but without the <<foo>> double-brackets non-hygeine) <paroneayea>(which seems possible; you can infer that something is a record and which record type it is afaict from playing around a few weeks ago) <taylan>amz3`: subtyping w.r.t. record types means you get a type whose members can pass as an instance of the supertype, but they also has additional fields not found in members of the supertype <paroneayea>taylan: how is that different from inheritance though? legitimately asking, I haven't understood really how this isn't the same thing, and it seems that there must be something <taylan>it's more or less the same as subclassing in a typical OOP system <daviid>paroneayea: but your are talking about a 'use' of generic functions here, with record support, which is fine (i thought we had that), I was talking about, if for scheme as in rs*rs, the design of 'an oop system', then that should be clos, immutable, thread safe ... i'm not talking about what a user do (or not) with it ... <paroneayea>daviid: btw I agree that we should have immutable and thread safe MOP support <daviid>and clos has a mop, the mop is the heart of the system <taylan>paroneayea: it's indeed the same thing conceptually <paroneayea>daviid: you've even seen that I've written up some code for it :) <daviid>goops has it of course, for the subset it implements, and I use it <paroneayea>taylan: is the difference that you don't have to associate yourself with object oriented programming? ;) <paroneayea>daviid: btw I've seen that in CLOS some people have implemented metaclasses that enforce the immutable side of things <paroneayea>daviid: it strikes me that maybe that's a direction worth exploring <daviid>paroneayea: did not read the link yet, but in the lisp world in general, and clos in particular, persistant means saving on disk, it has nothing to do with immutable <taylan>paroneayea: I'm really no "OOP hater", it's just that all the features of OOP systems I ever used were equivalent to what a module system plus subtypeable records offer, so the rest always seemed unnecessary <taylan>maybe I'll feel different once I encounter a few problems that are best solved with what OOP systems offer <wingo>guile-devel: the final frontier (of my inbox) <wingo>i am now caught up to november in guile-devel, just a few months to go! <wingo>civodul: any idea on whether our builds are reproducible now? <civodul>wingo: on 2.0 they definitely are; on 2.2 i didn't take the time to do a --rounds build yet <civodul>it should be reproducible but i haven't checked <civodul>i should do that during the night or something <wingo>i wanted to get a tarball out today but that failure-to-contify bug galled me :P <civodul>wingo: was there any conclusion regarding the gc-too-often issue? <wingo>civodul: no. i don't know what it is -- i mean you have a workload that will be causing the heap to expand; does the inline allocation implementation go through some different heuristic than the "normal" path goes through? i don't know. it's something we should be able to repro with just iota then if that's the issue <wingo>and if we can repro with iota we can repro with a small c program, and if that works we can send it to the bdw gc list and ask for advice <wingo>i checked a number of different footguns in guile and they had not fired, so i think it might be some issue with the functoin that inline allocation uses to replenish its free lists <civodul>i'll see if i can come up with a reduced test case <wingo>indeed ,time (length (iota #e80e6)) <wingo>that is a reduced scheme test case :) <civodul>with this: guix environment --ad-hoc guile-next -- guile -c '(length (iota #e80e6)) (pk (gc-stats))' <civodul>2.2 is slightly better than 2.0 (14 GC instead of 25) <civodul>and same story if the code is in a compiled file <civodul>iota is faster and conses less with ",o interp #t" :-) <paroneayea>LibrePlanet 2017 schedule is up, some here may be interested in my talk <paroneayea>You may have heard of Stallman and the printer, but much of free software's genesis involves the battle over the soul of the lisp machine. We'll trace Lisp and the Lisp Machine's roots, from its genesis in early hacker culture and the AI labs, to the split that (largely) pushed RMS to found GNU, through its role within and without the free software community. Why did GNU become a "Not Unix", and why not a lisp machine? What about the <paroneayea>role of Lisp within GNU, with projects like Emacs, Guile, and Guix? For those who are new to Lisp, there will be a mini-tutorial. <civodul>paroneayea: will there be live streams? <civodul>i think i'll virtually join the party <civodul>wingo: if we avoid the 'cons' primitive, everything seems ok: <civodul>scheme@(guile-user)> (define kons cons) <civodul>scheme@(guile-user)> ,time (let loop ((x #e80e6)(r '())) (if (zero? x) (length r) (loop (1- x) (kons 1 r)))) <civodul>;; 3.625901s real time, 3.631714s run time. 0.656535s spent in GC. <wingo>yeah it seems to be just uniformly bad <civodul>we'll ask ecraven to rerun the benchmarks once this is fixed ;-) <wingo>even if you do (for-each iota (iota #e1e4)), i.e. allocating but in a more ephemeral way, not growing the heap -- that's still more gc time than the "normal" thing <wingo>i mean more gc time than in 2.0 <wingo>civodul: if you looking into this, you can investigate changing each instance of "scm_inline_cons" etc for the other scm_inline usages in vm-engine.c to use the "normal" version <wingo>would be weird if that were an optimization for now, but there you go :P <wingo>maybe the path that we go through should be incrementing some counter or something <civodul>but it's only at the REPL that things go wrong <civodul>at the REPL there are 2 threads running; for "guile -c" there's just 1... <wingo>there is the signal handling thread, surely the sigaction at the repl will cause that to spawn off <wingo>might be a finalizer thread too <civodul>yeah, i meant Scheme threads returns by (all-threads) <wingo>good luck with the investigations :) <taylan>ACTION just added support for string fields to bytestructures. (utf 8, 16, and 32 as supported by (rnrs bytevectors). unit tests for utf 16 and 32 pending.)