<NieDzejkob>so, turns out you can fit a FORTH into 510 bytes <OriansJ>ekaitz: the only real problems I can predict with risc-v is the immediate formats do not map to the byte align behavior used in mescc-tools. So your binaries will not be efficient (but that should never be a primary concern as simplicity is the primary goal) <OriansJ>the reason for the large amount of subprojects is a reflection of the reality when breaking new ground that the best solution isn't known; so we encourage people to work on what they find fun. Sometimes it works out great (like live-bootstrap) and other times it ends up being a false start (slow-utils, lisp written in assembly, various FORTH projects, etc) and thus ultimately end up abandoned. <OriansJ>No one is assumed to be good at all things nor is anyone expected to know anything beyound what they find interesting or what they have worked on. So ask lots of questions and learn what interests you. Work on anything you find fun. <OriansJ>Hagfish: talent also tends to stay in environments which are enjoyable. A toxic environment will only drive away talent. So it is very important to keep things fun here while ensuring people treat each other with consideration while we bring alternate perspectives to the table as we hammer out our shared dream of bootstrapping the world. <fossy>well that's a bummer but oh well <fossy>flex 2.5.11 is not sufficient for bison 2.3 <fossy>like it compiles but its not reproducible <fossy>so i'm goign with 2.5.33 which compiles and is reproducible <fossy>(for scan-gram.c which i missed initlaly) <stikonas>fossy: hmm, sounds a bit annoying but I guess you got the solution now, so should be fine <fossy>stikonas: yeah i haven't added 2.5.33 to the bootstrap yet but it is a solution so <stikonas>well, we have a lot of different autotools, so I guess we can live with different flex/bison versions... <stikonas>at least they should be easier to build since we already have functional flex/bison. <stikonas>fossy: btw what kind of non-reproducibility was there? <fossy>stikonas: yeah it was in the generated c file <fossy>one of the lookup tables was non reproducible <fossy>some values got moved around <gforce_de1977>shorten the path is something for the future, for now just choose at least *a* path 8-) <pabs3>did folks see the freenode drama yet? will this channel move elsewhere? <siraben>FYI, I have claimed bootstrappable over on libera.chat <siraben>please let me know if you want me to transfer OP ***ChanServ sets mode: +o rekado
<bauen1>if we're going to transfer, wouldn't oftc make a bit more sense ? <stikonas>I think most channels will be moving to libera.chat though... <bauen1>strictly from a stability standpoint, but yeah <stikonas>and guix if it moves will got to libera.chat <bauen1>true that's a good argument, so are switching now or is that still not really decided ? <stikonas>bauen1: well, there is a channel already there <stikonas>but it will take some time for people to move... <mid-kid>I just hope we get a global ping or notice when the channel moves <mid-kid>Most of my channels are on freenode so I'm a bit scared <stikonas>most of my channels are on freenode too... Some will take longer to move (e.g. all KDE channels) because they have to register as organization... <nckx>stikonas: <and #guix if it moves will go to libera> Nothing like that has been decided, or even discussed, but as far as I'm concerned it will. <stikonas>nckx: somebody mentioned it there on #guix, but maybe prematurely... ***Server sets mode: +cnt
***Server sets mode: +cnt
<stikonas>siraben: can you remove "r" from the channel on libera, so that bayfront-log can join ***Server sets mode: +cnt
<OriansJ>well the migration of #bootstrappable from here to irc.libera.chat is going to be based on what the majority of developers want. So if you have written code for this project in the last year. Respond with stay or go to irc.libera.chat in the next 7 days. If more people respond stay, we stay but if more respond go we go. any objects? <vagrantc>i don't know if packaging mes or mescc-tools counts as writing code ... but the whole freenode situation sounds pretty disappointing <OriansJ>vagrantc: completely fair question. I am going to count all non-coding contributions too if the vote seems close or if developers largely don't care either way. So tag your response with [support] as your contribution does matter. ^_^ <OriansJ>(I also am not going to count contributions that occur after the time of my post to avoid any gamification of the voting) <xentrac>dunno if i get a vote (does the ur-scheme test suite count as code in the last year, maybe not) but i'd say go <xentrac>because freenode is freenode's staff, this new thing called freenode is just some power-hungry wanker with pretensions to royalty <OriansJ>xentrac: yes that is code (scheme code to be precise) <OriansJ>vagrantc: all non-coding contributions are accepted with the [support] tag (no proof required but also will not impact the outcome unless the developers can't agree) <stikonas>OriansJ: I think some people would prefer to stay on both channels for the duration of transition... <stikonas>and if people just stay in two different channel, then this week will be very disruptive... <OriansJ>stikonas: that is fine, I didn't ask anyone to leave if they opt for go. Also erc is happy to support both. <stikonas>well, longer term both is probably inconvenient... <stikonas>I was just thinking of really short term