IRC channel logs


back to list of logs

<rlb>Huh? Maybe my expectations are wrong?
<rlb> scheme@(guile-user)> (define foo (make-thread-local-fluid 1))
<rlb> scheme@(guile-user)> (fluid-ref foo)
<rlb> $1 = #f
<RhodiumToad>that's quite weird
<alextee[m]>hi, can someone convince me that guile is better than python? ie, how does guile handle packages and environments?
<daviid>rlb: (fluid-ref* foo 1)
<RhodiumToad>that's ... not documented
<daviid>rlb: i think this is because "fluid created with make-thread-local-fluid won’t be captured by current-dynamic-state and won’t be propagated to new threads"
<RhodiumToad>I mean fluid-ref* is, but the behavior of make-thread-local-fluid like that is not
<RhodiumToad>I'm looking at the C code and I can't see why
<daviid>and 'practically', you will probably use those (any) fluid(s) within the contet of with-fluids, and that works ...
<RhodiumToad>so fluid-ref first checks a local cache which won't have the value since we just created it
<RhodiumToad>then it does scm_hashq_ref(dynamic_state->thread_local_values, fluid, SCM_UNDEFINED)
<RhodiumToad>and that should return SCM_UNDEFINED since the value's not there? (nothing can have added it yet?)
<RhodiumToad>then it does if (SCM_UNBNDP (val)) val = SCM_I_FLUID_DEFAULT (fluid);
<RhodiumToad>and I checked that the default value really is in the fluid cell where it should be
<RhodiumToad>so I literally do not see where the #f is coming from
<rlb>At least from the docs, I'd have assumed that the dflt provided to make-thread-local-fluid would be the default in all cases where there wasn't an intervening with-fluids, etc.
*RhodiumToad too
<rlb>otherwise, what's the dflt for?
<RhodiumToad>and I'd make the same assumption from reading the C code, which means that there's something weird going on that I'm not seeing
<RhodiumToad>I literally cannot find any code path that results in returning #f
<daviid>I agree , I just tried 'a bit out of the blue' ...
<rlb>Well, #f is the default if you don't provide a dflt, I think, so maybe that's at play here.
<rlb>Anyway, I can work around it, but wondered if I was misunderstanding or should file a bug.
<RhodiumToad>but that default is set in the make-thread-local-fluid func
<RhodiumToad>return new_fluid (SCM_UNBNDP (dflt) ? SCM_BOOL_F : dflt, ...
<rlb>Yeah, you're well ahead of me -- haven't looked at the code yet (2.2.6 here).
<RhodiumToad>also 2.2.6 here
<rlb>In any case, thanks for the help wrt sanity checking.
<RhodiumToad>and I checked by peeking at the fluid with pointer->bytevector that the value 1 was actually in the fluid's cell
<rlb>And it was, I take it?
<RhodiumToad>also if it wasn't, then (fluid-ref* foo 1) wouldn't have worked
<rlb>hmm, noidea -- perhaps a bug then?
<rlb>If so, should be easy to add a test once we track it down.
<RhodiumToad>I see it
<RhodiumToad>I would call it a bug
<RhodiumToad>here's why it happens
<RhodiumToad>when fluid-ref fails to find the value in the cache, it looks for it in the thread_local_values hashtable
<RhodiumToad>which it accesses with scm_hashq_ref(dynamic_state->thread_local_values, fluid, SCM_UNDEFINED) as I mentioned above
<RhodiumToad>but passing SCM_UNDEFINED as the third value there makes scm_hashq_ref think that no default was supplied, so it substitutes #f
<RhodiumToad>I think the more correct way would be to do
<RhodiumToad> scm_hashq_ref(dynamic_state->thread_local_values, fluid, SCM_I_FLUID_DEFAULT (fluid))
<RhodiumToad>or use scm_hash_fn_ref but that's a bit uglier
<RhodiumToad>looking at the git repo, this hasn't been fixed
<RhodiumToad>hm, even that only works because you can't make an unbound thread-local fluid
<rlb>RhodiumToad: ok, so if it still seems like a bug would you like to file one, or should I?
<RhodiumToad>please do, you can include my analysis above
<rlb>Sounds good -- I'll try to get to that tomorrow. Thanks for the help.
<daviid>I wonder what the test-suite checks about this, didn't have time to look at it ...
<RhodiumToad>there are no tests for thread-local fluids
<rlb>And regarding the (future 1) call at the top-level problem (locks up compilation), I just worked around it by creating an actual goops wrapper class around the scheme future (which is acceptable for now in the case I care about), but it'd be nice if we eventually have a sensible way to specialize goops methods on futures.
<RhodiumToad>there's a test that normal fluids have thread-local values, that seems to be all
<rlb>mooooore tests...
*rlb likely wanders off for a bit
<RhodiumToad>looking at the code, the bug appears to be primordial, dating from the addition of thread-local fluids
<zig>alextee[m]: Guile does not have GIL :)
<RhodiumToad>I suspect python has better libraries
*RhodiumToad does not do python
<rgrinberg>How does goto definition work in geiser? Does it send a command to guile to get the location of a symbol?
<rgrinberg>I see this lookup-procedure function, but I can't its definition anywhere
<zig>btw there is
<zig>not tested tho
<zig>and wip
***wxie1 is now known as wxie
<johnjay>can i embed guile into any old C app and get a bunch of libraries to use for stuff?
<str1ngs>johnjay: you can embed guile into C programs yes. I don't understand the libraries question though.
<johnjay>i saw a talk on youtube about how guile had a bunch of libraries for things
<johnjay>you know, xml, networking, databases, parsing regular expressions, etc
<johnjay>i'm saying, if i embed guile do i get a bunch of stuff like that for free?
<str1ngs>right, if you embed guile into a C program. then you can call any guile scheme code from C
<str1ngs>there are some caveats though like threads and memory management mainly on the C side of things mind you.
<johnjay>i thought about doing a project to try it out.
<johnjay>i just wondered what my expectations should be
<str1ngs>I would only use C if there is a very good reason for it.
<johnjay>well i have projects in C already
<johnjay>so that's why i want to test it
<str1ngs>that makes sense then
<johnjay>is guile like for c++ or something only?
<str1ngs>guile only has a C interface. but you can use it with C++
<johnjay>ok. the only concrete example I can think of what i want is gimp
<johnjay>where you can script things in scheme
<johnjay>is guile scheme involved with Guix too? i thought i read that
<str1ngs>use guix uses guile scheme
<johnjay>ok coool.
<johnjay>there's a lot of other schemes so i just wanted to look for reasons to try guile
<ArneBab>alextee[m]: for my argumentation, see — it stayed the same the past 4 years, though I now have more refined solution in Guile.
<ArneBab>… and though Python adding async and await as keywords broke some an old Python codebase I maintain (but did not write)
<alextee[m]>ArneBab: interesting read, thanks!
<ArneBab>the full pdf is available for free: (as nagware — to get rid of the "please buy me" pages, just build it yourself after removing the part which includes nagware)
<bandali>ArneBab, hey, can i /msg you with a quick question?
<rlb>johnjay: fwiw, make and gdb can now also be built with guile support, though I haven't used it in either much yet.
<johnjay>rlb: how would you use guile in make?
<str1ngs>johnjay: for C or for compiling scheme byte code?
<str1ngs>or maybe you meant guile support in make?
<johnjay>yes. make kinda just does one thing so idk how you could extend it
<str1ngs>it depends on what you are trying to do johnjay . build a C program with guile support, build scheme byte code. or use guile for make recipes
<rlb>In both those cases, it's used for extension.
<rlb>I don't know the other, current schemes all that well, but I'd say that Guile's quite good if/when you need to integrate with C or C libraries, or if you think you might eventually want to use C for performance critical parts, as is often done in python, but unlike python, guile has (more serious) threading support, and I suspect better performance. As compared to say the jvm (perhaps for example clojure), guile is much lighter-weight
<rlb>(than the jvm, though that's gotten better these days), much better startup time, and good support for *nix apis (including for example filesystem sockets).
<rlb>...but I suspect guile doesn't currently have nearly the breadth of "easily accessible" extension libraries like python and say clojure do (and maybe the other schemes).
<ArneBab>johnjay: I used guile in make to get its string handling when doing the same with shell functionality got too annoying.
<zig>does anybody, by any chance, has multithread based web server implementation around?
<zig>also it should pass to the handler the client port :)
<zig>I want to do a quick project, I have all the pieces except that webserver, to be feature complete.
<rlb>zig: I imagine you've seen this? (don't know offhand if it's threaded)
<rlb>(And the section after that has examples.)
<rlb>zig: wait, that was the wrong link...
<zig>rlb: I saw that, thanks. Actually, it not very difficult to hack together multithread server using the code from (web http), I mean got some thing together, will see if it works.
<johnjay>ArneBab: ah ok so you changed the way make functioned directly
<soda__hobart>what do I do if I get an unbound variable error because it says a module binding overrides a guile binding?
<soda__hobart>I tried using the #:select and #:prefix keyword args with (use-modules) to assign a namespace prefix to resolve the problem,but then I get an error saying that the module doesn't have that binding :|
<rlb>Think I'd have to know more about the context -- e.g. is it complaining about a (define foo ...) in your module when you've already imported a foo from somewhere else, or...?
<soda__hobart>I get `WARNING: (guile-user): `quit' imported from both (guile) and (redis)` and then I get a the resolve-variable procedure throws an unbound variable error.
<rlb>Hmm, not sure if you've tried this, but in general, I tend to always use select these days, and so I'd probably ((redis) select: (...)) omitting quit if I didn't need it, or renaming it if I did, i.e. ((redis) select: (... (quit . redis-quit) ...)) or similar.
<rlb>i.e. clojure convinced me to generally name all my imports -- it's wordier, no doubt, but it's a lot easier to track things down when I come along mater.
<rlb>(or if I'm looking at unfamiliar code)
<soda__hobart>so that's the thing, I did that, but I got: `no binding `quit' in module (redis)`
<soda__hobart>I'm down with naming all the imports, I think that's a good practice in general
<rlb>Hmm, that makes me suspicious -- have you tried narrowing it down to a really small test example?
<rlb>say just a single file containing something like this:
<soda__hobart>yeah, it's so weird. I've been working on this project for a few weeks and have not encountered this problem before. If I just go in the REPL and do (use-modules (redis)), everything works fine.
<rlb> (define-module huh
<rlb> #:use-module ((redis) #:select (quit . something-else)))
<rlb> (display something-else) (newline)
<rlb>And then run it with guile -s foo.scm
<rlb>plus or minus a suitable GUILE_LOAD_PATH=... guile -s foo.scm
<rlb>If that works, then likely something else in your actual file is interfering...
<soda__hobart>yeah, did that, no luck
<rlb>so that simple example crashes too?
<soda__hobart>yeah. I was trying to define a module earlier, but then stopped making changes to that file. Could that have anything to do with it?
<rlb>Well, every now and then I'll apply the sledgehammer "just to be sure", i.e. here "rm -rf ~/.cache/guile/ccache/2.2-LE-8-3.A/home/rlb/whatever/dir/im/working/in"
<rlb>i.e. to make sure some cached bits aren't causing trouble (and force all the macros to be recompiled)
<soda__hobart>I'll try that. I've never made a module before, so I probably screwed something up with some haphazard calls to (define-public) and (define-module)
<rlb>but I'd guess that's not going to help here, if I had to guess.
<rlb>was the error on the trivial foo.scm the same as the one with your normal file, I guess?
<rlb>And is there any chance the load-path is different between the case you care about and the case in the repl where it "works"?
<rlb>i.e. maybe you have a broken redis in one case...
<soda__hobart>yeah the trivial error is the same one as on the normal file (which is still pretty trivial, haha)
<rlb>oh, and if it *were* the cached files somehow, you'd of course need to clobber all of them that matter, i.e. the ones for redis too, if that's in some other tree.
<rlb>You can compare the load-paths by printing %load-path in both cases if you like.
<zig>seems like I have the pices for my guile plan of the week end }:)
<zig>all the pieces
<soda__hobart>hm well maybe I'll restart the computer, maybe reinstall these modules
<ArneBab>johnjay: no, I just used guile in a rule
<ArneBab>via $(guile …)
<zig>I got brilliant idea for few days worth project, see
<zig>the server is written in guile :)
<jcowan>Nice. You might want to ship it in a container
<zig>jcowan: that is what I was thinking, guix pack --format=docker
<zig>or something.
<daviid>zig: why don't you push your idea(s) on sourcehut instead ... and definitely close your github account ... for a good 2020 start :)
<zig>that is an idea, I am thinking about a lot. But honestly I can not close my github account for the time being...
<jcowan>I have no desire to leave Github, as part of my stuff is still on Bitbucket
<ArneBab>I have a strong desire to leave both bitbucket (kills hg) and github (m$) …
<ArneBab>But I wish I could automate changing every single BitBucket URL …
<ArneBab>I used them because I thought "it’s a profitable company, repositories there will persist". Ha…
<alextee[m]>i use cgit and mirror my stuff on github/gitlab/framagit etc
<alextee[m]>it's very easy to mirror stuff with crontab and a git --mirror
<ArneBab>does this still apply if it has to continue working without major maintenance for 10 years?
<zig>there is software heritage for that, no?
<ArneBab>can I throw them links to repositories to ask them to keep them available?
<ArneBab>same for me …
<zig>they partenered with github also
<zig>I hope they support source hut or will.
<daviid>be careful with github and other 'such' companies, always prefer those association/ong ... like sourcehut, that strictly respect the fundamental human rights, such as privacy, zero tracking ... not to mention the danger that of all of sudden, 'they' apply some of their terrible clauses of their unacceptable contract(s) ... these compamies can die/disapear, the sooner the better ...
<ArneBab>what I also like about is that I can easily pay for an account
<ArneBab>… just need to get to doing it …
<ArneBab>… or not. No credit card …
<daviid>ArneBab: send an email or ask how you can acheive a payement on (freenode, ddevault is the author)
<jcowan>ArneBab: I'm using to mirror my BitBucket hg repos on Github, so when the time comes I just switch.
<jcowan>It's a free service you just set up.
<daviid>nothing is free with these bad companies, that's an illusion
<jcowan>The vast majority of all companies are honest and ethical, and there is no shortage of crooks in the nonprofit sector.
<daviid>in my experience, the vast majority of all companies everywhere in the world, are unhonest and unethical
<jcowan>That's as much as to say that the people who make them up are. And if that were so, business would be impossible. "Trust, but verify"
<daviid>you can't trust any company anywhere in the world
<jcowan>I presume then that you have taken the precaution of acquiring modern weapons, including artillery and missiles?
<zig>I was foolish to say that is a couple of days of work.
<zig>As usual.
<jcowan>How to estimate: Take your best shot, double it, and move up to the next higher unit of time.
<jcowan>Thus 1 day = 2 weeks.
<daviid>'artillery and missiles' are a 'corporate/cmpany' terrible vocabulary, but if I had to quote you, then I'd say my 'artillery and missiles' are free s/w and education
<jcowan>What good are those if you can't trust your neighbors not to attack you, steal from you, or cheat you, since they are so corrupt and unethical?
<ArneBab>jcowan: I don’t want to go to go to github
<ArneBab>jcowan: but I just discovered
<ArneBab>and am trying to add "if name not allowed, prompt for new name"
<daviid>I'am sorry to hear that you have neighbours that threaten you that much, I don't have this problem, but then I teach them what free s/w, to use free s/w and why ... and offer to also educate their children, then they thank me ...
<daviid>anyway, back to hack
<spk121>I like github. I do put the release source tarballs on a javascript-free personal site, though, for people that worry about that sort of thing. Although that non-github, non-javascript website is hosted by GoDaddy over the AT&T backbone
<zig>(maybe it will be ready for 2020-01-01)
<jcowan>daviid: Of course I don't, and probably neither do you. But if the companies are Evil, their employees are servants or masters of Evil, and that includes your neighbors. But you're right: enough of this.