IRC channel logs
2025-06-16.log
back to list of logs
<adhoc>have you tried doing a dns lookup for the domain ? <Ironsmith>adhoc: when i do nslookup it directs me to 209.51.188.116 which coincides with what it should be, and i can ping it, and ping gnu.org, but when i try to get anything out of port 80 or 443 =( which is why i'm asking if there's any mirror anywhere <Ironsmith>i have been looking at the manual vigorously, maybe that's why i'm being blocked, and it's not the first time <Ironsmith>by vigorously i mean i have a few tabs open on the one-page version of the manual (3 tabs or so) <adhoc>Ironsmith: i wonder if there is a PDF file you can cache locally ? <Ironsmith>oh yeah maybe i can try to use my browser's local cache version... good suggestion @adhoc, let me see if i can do that instead, because yeah that pdf i found is a little old <adhoc>i was thinking about the pdf file <adhoc>as you can still search through that =) <Ironsmith>ah gotchya, humm yeah next i can access gnu.org, i'll be sure to download a copy hahaha <rlb>Ironsmith: unless you were doing something fairly unusual, I'd be surprised if gnu.org was throttling you. Could also try a traceroute (mtr --curses gnu.org or similar), might or might not tell you anything useful. <Ironsmith>thanks for the tip rlb, humm this is what mtr is showing me: <host> (<loss %>): my-machine -> router.home.local (0% loss) -> 10.x.x.x (0) -> ??? (100) -> x.x.x.atlas.cogentco.com (0) -> sea-b1-link.ip.twelve99.net (0) -> chi-bb2-link.ip.twelve99.net (80) -> ewr-bb2-link.ip.twelve99.net (70) -> bost-b4-link.ip.twelve99.net (0) -> <Ironsmith>towardex-ic-372977.ip.twelve99-cust.net (0) -> bbr01-fh-0-2-0-7.bsn05.twdx.net (0) -> dcr03-fh-0-10-0-19.bsn04.twdx.net (0) -> mass-ix.fsf.org (0) -> wildebeest1p.gnu.org (0) <Ironsmith>apparently that '???' is common and represents something on my local network? looks like it's past my fibre modem though. my first time running mtr <rlb>If you have access to some host outside your network, might also want to try a "curl ... > /dev/null" and see how that goes. <wingo>hoo, print states. gnarly stuff <wingo>current status: a slog to get everything precisely markable, i am moving off smobs internally. we may or may not still allow them for users but without some additional API, declaring a smob type would turn off defragmentation <wingo>three more data types remaining internally <civodul>would using SMOBs effectively equate with having worse performance? <wingo>civodul: short answer: yes, if smob use prevents defragmentation. <wingo>that need not be the case: we could allow for users to supply trace functions (like mark functions but they operate on slot locations instead of the values in the slots), but i am not sure if that will be possible <wingo>anyway, still in an experimental phase, we can figure out what to do later if no-smobbing is a win <rlb>dthompson: regarding your json proposal, would you consider (optional) customization of the data structures out of scope? e.g. for edn elsewhere, I'd tried this -- https://codeberg.org/lokke/lokke/src/branch/main/mod/lokke/scm/edn.scm#L58 and you might have a json-reader function e.g. (json-reader #:constructors ...) or similar that returns a customized reader. Presumably read-json would just be a pre-built "default" parser. <rlb>(fwiw I did that so that you could use the same edn parser producing either proper scheme structures, or clojure persistent strutures, and ideally it'd be nice to be able to do the same on top of guile's json parser if we had one...) <rlb>(for lokke, or perhaps other languages -- say elisp wrt nil, etc.) <dthompson>rlb: personally I think it's most useful to have a single format that round trips <rlb>sure, as the default <rlb>i.e. I agree that's what read-json should do. <rlb>But of course, I'd have to write a nearly completely duplicated parser for clj (or maybe something else) "just" to change the vectors and maps. <rlb>So if there were *also* an escape hatch (json-parser #:constructors ...) that'd be nice, and at least for edn wasn't much extra code. <rlb>But of course could be there's no general enough common ground. <dthompson>this feels like a uniquely lisp kind of problem. other languages don't do this. no one asks for an escape hatch to JSON.parse in javascript. <rlb>In lokke's case, everything else was "the same", i.e. lokke and edn both chose #nil (at least atm), and edn has keywords in its maps... <rlb>Well, in my case, it's a polyglot problem -- i.e. if I want to share across two languages, so perhaps more esoteric. <rlb>Anyway, just wanted to see what you thought -- I *could* see wanting an easy way to get a particular flavor of hash tables for maps, but perhaps also out of scope for what you want here. <rlb>(in certain situations -- agree the default for read-json should be alists) <rlb>Oh, and fwiw, I wondered about (web json) too -- i.e. no idea what it should actually be named, but imagined we might want some subtree for "formats" instead, e.g. (guile coding json/edn/elisp...) or whatever. (I'm fine with ice-9, but if people don't like it, I'd thought about favoring guile as a new top-level that we reserve for anything guile itself provides.) <rlb>Though wrt sticking to a reserved top-level or two, I do think it's fairly nice to just obviate the potential for future conflicts. <dthompson>iirc the scheme standards people do not recommend using the implementation name as a namespace <dthompson>I thought (web json) made sense because it's a web technology <dthompson>the ice-9 namespace needs to be retired, imo <rlb>OK, didn't know that -- I just tend to favor not having an unmanaged namespace where both guile and external packages can't know what's "safe" to pick. <rlb>So if we were to reserve one or more names and stick to it, (that) problem solved... <old>dthompson: json is far from being only used in web. Don't put it there please <old>why not (parser json) ? <dthompson>I don't really feel like bikeshedding about the name. if it ever gets reviewed by a maintainer they can make a judgement call. <old>fine. So don't put it in web since it's not just for web <rlb>Only asked because I'd started looking at it a bit, and while I'm unlikely to merge it on my own, I definitely wouldn't feel comfortable picking the module name by myself. <rlb>(Just wanted to see how you felt about it.) <rlb>I *do* agree with the idea of having something like it in guile (the more important point). <dthompson>I'm fine with it being placed elsewhere, but I stand by (web json) as one of possibly many sensible names. <rlb>Unrelated -- does anyone know a better way to share (ice-9 exceptions) between (ice-9 read) and a srfi, without adding them to the global namespace -- than (the ugly hack of) a "%private" hash table shared in boot-9.scm? <rlb>It's been a bit, but iirc, you can't just use the modules normally at that point in the process there. <daviid>fwiw, I don't think we should retire the ice-9 namespace, and (ice-9 json) would be, afaic, perfect, my 2c <ieure>ice-9 is a *very* confusing name for anyone approaching the language. <daviid>another possibility would be to have its own namespace, why not, we do this for sxml <Arsen>I don't disagree with it not being a great way to say "standard library", but it didn't confuse me much even when I was new (it was pretty much a case of "oh, so they call it ice-9, okay") <rlb>Maybe I'm wrong, but I'm really wary of many top-level namespaces for guile itself -- wrt the potential for collisions. <Arsen>> Updated: 2009/06/25 22:12:40 ossau. <rlb>Agree we should at least make sure it's well documented, i.e. perhaps should be the first thing you hit if you "C-s" search for ice-9 in the info pages. <rlb>ACTION might see about that <Arsen>i don't think there's on specifically for ice-9 rn <daviid>ieure: they just ask, and we ask the bot to exaplin ... it is a one quiz solved for ever - i don't think (guile) newcommers are any less able to learn then we did long time ago ... <rlb>Personally, I happen to like ice-9, but I understand others don't. <daviid>that's it, now all newcommers in this channel know :-) <daviid>ieure: making people search is a (very) good thing <daviid>but since we do have a specific sxml namespace dedicated to 'the all xml' parsing and 'friends', we could do this for json as well, which would also allow to add specific module if needed <daviid>(json simple) might be a good start, it would also 'mimic' the sxml namespace, so to speak <old>when I've first learnt Guile, I though ice-9 was a third party library and avoid it lol <old>you can't expect users to read the entire manual to understand your language <daviid>old: sorry, but that doesn't make sence, another library would need add-to-load-path, it is prety obvious that ice-9 ...) are guile modules in the ice-9 namespace <daviid>and asking why the namespace name doesn't require to read any page of the manual <old>yes but that is something a new user dont' uunderstand very well <daviid>that is the guile module system ... can't expecte thjem to know w/t learning and asking for help if needed <old>they will have too at some point <Arsen>scheme@(guile-user)> (use-modules (haunt asset)) <Arsen>yes, which you might've inadvertently done as a dependency of something lse <daviid>which by default uses guile site (which it shouldn't, it should only do that if the user permits it <old>well maybe I did something wrong in your standard of learning new language, but I recall thinking that ice-9 was not the standard library. that's just a fact and I am not alone in that boat <daviid>i have this idea that no external app/lib should ever be installed in the guile tree by default, but only doing so with user permission, hence my --with-guile-site in my packages <Arsen>I can definitely see it happening <Arsen> 22:38:29 <daviid> i have this idea that no external app/lib should ever be installed in the guile tree by default, but only doing so with user permission, hence my --with-guile-site in my packages <Arsen>running 'make install' is the permission, no? <daviid>Arsen: it is not an autoconf 'specificities', it is a package author decision, and implemented using the autotolchain yes <ieure>Well... not gonna argue, since it seems pointless, but even with years of experience in multiple Lisps, I ended up getting a stack trace full of ice-9 / boot-9 stuff and wondering what the heck any of it meant, then having to search it. If it was (guile stdlib) or something like that, would have been obvious from the get-go. <rlb>One key concern I have with guile itself not sticking to reserved namespaces is that depending on how serious we want to be about not breaking backward compatibility, it means we can't add any new modules in a Y release. <rlb>Unless we don't consider that kind of potential breakage part of our contract. <daviid>rlb: adding a namespace isn't a breaking backward compatibilty? <daviid>it wuld if you remove a namaspace <old>If you have a package (something) in version A, and then version B introduce that same namespace, that package is now broken <old>I guess you can call that breaking backward compatibility <Arsen>ACTION doesn't think anyone using the namespace "guile" other than guile itself is being reasonable <daviid>it certainly isn't a bckw breaking if guile names one of its new module as 'your personal' one, and just as I pointed abovce, you ahould never fill guile's tree with your module anyway <daviid>back to hack, i said what i had to say ... maitainers will decide anyway <old>I'm not understanding something here, I never mentionned adding Guile in the namsepace <old>I think the point of rlb is that if we start adding new top namesapce like (json), you are effectively breaking other peoples modules that might be just (json) as well <old>ofc, it Guile introduces (guile json), then it's fine <daviid>old: I know you didn't, what I am saying is guile naming its new namespace json is not a backward breaking compatilibity, by definition, a backward breaking compatibility can only be from guile wrt guile, not user modules <rlb>Arsen: right -- I was inclined to formally reserve (explicitly document) say ice-9 and guile and then just stick to those, but dthompson said that that might actually be discouraged by the standards people. <daviid>and i also suggest a namsace, so there would be at lest one module, like (json simple), not (json) <rlb>daviid: right, the API breakage (if we chose to agree) would be if say guile-json had chosen (guile json) and then we released guile 3.x with our own, incompatible (guile json). Now we've broken anyone that had an app depending on the existing one. <rlb>daviid: I don't yet know what the origin of that discouragement was. <rlb>And of course there's no way to know what we might break since there's no global registry or whatever -- hence the urge to reserve and limit ourselves. <old>rlb: I think it is fine to keep two roots for guile (ice-9 ...) and (guile ...). Not sure why that would be a problem nor why we should listen to the standard peoples when Guile is far from being standard scheme anyway <daviid>guile-json is an exzternal library, users will obviously have to deal with that, by uninstalling and migrating, or install their (guile json) elsewhere then in guile's tree <rlb>dunno -- just my natural inclination. On the clojure side I'm used to them effectively sticking to org.clojure.*, but they're also part of a much broader ecosystem. <rlb>daviid: yes, but if it happens often, it's a pretty unpleasant experience for users wrt choosing guile as a platform, and one that's easily avoided. <rlb>(with just a touch more typing (once) in the use-module statements) <daviid>any language user knows that their module may one day 'clash' with the/a language newly added module <rlb>Doesn't have to be true, and isn't in clojure. <Arsen>ACTION was once surprised to find C++ reserves ::posix <Arsen>it only took becoming an implementor of C++ to figure that out :^) <old>just look at to what extend C goes to avoid any kind of name clashing with respect to header files, types, functions, variables, etc. <rlb>Of course clojure's a(n excellent) outlier there -- clojure itself *very* rarely breaks backward compat. <daviid>but it not a backward compat, I stick by my def of what a backeward compat is - off this discusion now, also stick to my proposal to add a json namespace, with a 1st (json simple) module <Arsen> 22:56:42 <old> just look at to what extend C goes to avoid any kind of name clashing with respect to header files, types, functions, variables, etc. <old>Arsen: the important statement here: the associated header is included. <old>already defined `bool`? Fine, don't include <stdbool.h> <Arsen>jokes on you, that's a keyword now ;) <old>don't compile to C23 then <old>use what then if I may ask <daviid>you already defined (json)? son't (use-modules (json simple)) ;-) <old>Oh god. If I can avoid it, I will <Arsen>that's silly, it's pretty much a direct upgrade <old>if you call that upgrade. I don't <daviid>i'd pick GLib/GObject, then your new lib is introspectable by nealr all languages on the plaet <daviid>otherwise, I'd stick to guile scheme and goops, with very limited C code, when there is no other way (like 'calling' GObject macros from scheme for example) <daviid>or for performance reasons, like I (have to) do in guile-cv. but the memory allocation is entirely performed in scheme, just calculus in C. this because I use vigra, which stores an image as f32 vectors (not arrays), and srfi-4 can't process those vectors w/t converting their content (floats) from C to scheme - performing pure calculus in C, in guile-cv, is 100x faster, in average