IRC channel logs

2020-09-17.log

back to list of logs

<matijja>I see. But not understand much. Why not just (eval-when (compile) (define compile-date (current-date)))
<ft>I don't use that thing much, so I'm not an expert. I'd take the advice at the end of the section, or slowly work yourself into it.
<matijja>With same technique I can get program-name/version from environment (with is available at compile time) into untime, i think...
<matijja>This example in info doesn't works for me. The time is changing every time I run the program.
<RhodiumToad>is it being recompiled each time though?
<matijja>I don't think so, only first time show me the info of compiling.
<matijja>Here is my example: https://paste.debian.net/hidden/ea7b70c7/
<RhodiumToad>hm
*RhodiumToad also hasn't used that thing much (if at all)
<matijja>I solved the problem with defmacro: https://paste.debian.net/1164130/
<mwette>sneek: later tell matijja, use syntax-rules rather than defmacro
<sneek>Got it.
<nalaginrut>morning guilers~
<matijja>Morning.
<sneek>Welcome back matijja, you have 1 message!
<sneek>matijja, mwette says: use syntax-rules rather than defmacro
<matijja>mwette: I will try again, but I didn't have luck with syntax-rules...
*spk121 considers entering tomorrow's Lisp Game Jam
<daviid>spk121: fun! will you propose something using guile-gi?
<spk121>I've got my own weird game engine in a repo somewhere. C Gtk layer + guile scripting
<daviid>ah ok
<spk121>daviid: haven't tried to code anything in months because of real life. I wonder if I still know how? haha
<daviid>:) - i am sure you know,but i understand the feeling :)
<daviid>spk121: while you were 'in real life' :), i managed to get GInterface as classes and 'just using multiple inheritance' to implement this weird java 'way of things' that GObject itself inherited :)
<daviid>so far so good, but i have some finalization work to do still - so i didn't push yet
<spk121>daviid: impressive. GObject is a strange beast
<daviid>spk121: here is an example that uses that newly implewmwented 'way of things' in g-golf - https://paste.debian.net/1164139/
<daviid>in previous versions, i'd have to use VBox HBox, and line 33 would have raised an exception ... the 'orientation g-property is writable as well, so now, one can change the oientation 'on the fly'
<spk121>looks like it is all there, congrats
<daviid>tx, almost, the last thing i need to fix is when signal(s) expect an interface as one of there argument, like the 'open signal for GApplication, so far, g-golf still 'uses ...
<daviid>still 'uses'(expect and returns) pointers ...
<daviid>I hope to finalize this the next few days now - today i fixed another very annoying bug related to 'promoting' guile core procedures (and user procs) as gf ... that consumequite a bit of time the last two to three weeks :), but i think i 'really' did fix it
<daviid>so i' just offered myself a glass of wine :):)
<daviid>haha - then i won't be able to code either :)
<spk121>daviid: it has been quite a long haul, and now you are in the home stretch
<spk121>(to mix driving and sports metaphors...)
<daviid>spk121: :) - I wish good luck and more importantly good fun with the lisp game jam, let us know how it went ...
***apteryx is now known as Guest94283
***apteryx_ is now known as apteryx
<ArneBab>Do we already have some linting for Guile? I’ve been wishing for that for a long time, and now I have one more reason to ask here :-) https://news.ycombinator.com/item?id=24501803
<dsmith-work>Hey Hi Howdy, Guilers
<rlb>New upload of guile 3.0.4 failed to build on s390x with:
<rlb>Running suspendable-ports.test
<rlb>UNRESOLVED: suspendable-ports.test: non-revealed port is closed
<rlb>ERROR: suspendable-ports.test: revealed port fdes not closed - arguments: ((system-error "seek" "~A" ("Bad file descriptor") (9)))
<rlb>
<rlb>Known issue by any chance?
<rlb>The other release architectures were fine, but a few of the older ones were not: https://buildd.debian.org/status/package.php?p=guile-3.0
<nalaginrut>civodul: may I request the progress bar or percent of `guix refresh`?
<nalaginrut>sometimes I thought it's halt ;-)
<civodul>nalaginrut: ah, true
<civodul>you run it without arguments?
<civodul>it's often not very useful to do so IMO
<nalaginrut>wat? guix refresh needs a specific package?
<nalaginrut>then maybe it should just throw a simple usage and quit ;-O
<nalaginrut>civodul: how can I install guile with readline from guix?
<nalaginrut>it seems no readline support by default
<manumanumanu>matijja: The problem might be that your modules are declarative. That means they do very agressive inlining of variables, and a set! might not work as you expect.
<manumanumanu>matijja: at least since guile 3.
<manumanumanu>If you want to hold state in a module, you either make it #:declarative #f, or you store the state in a box or use parameters. The box will make it faster, whereas you will get a more dynamic behaviour from parameters, where users can change parameters in dynamic extents of (parameterize ((your-parameter 'no-logs-please)) ...). your-parameter will have the value 'no-logs-please for everything in the body,
<manumanumanu>even in procedures called by the body
<manumanumanu>but outside the body, it will be whatever value it was before.
<manumanumanu>boxes will be slightly faster, but have all the downsides of mutation: threads might not work.
<RhodiumToad>I think the question was how to compute something at compile time that would then be treated as constant
<manumanumanu>RhodiumToad: i missed that part of the discussion. the defmacro solution is adequate then!
<RhodiumToad>why doesn't the docs example for it work, though?
<manumanumanu>I only saw "can guile modules hold state"
<manumanumanu>RhodiumToad: link?
<RhodiumToad>see under "eval when" in the doc
<RhodiumToad> https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/Eval-When.html#Eval-When
<manumanumanu>dang
<manumanumanu>because %date expands to (date)
<RhodiumToad>I think that example _shouldn't_ be compile-time constant, but it certainly gives the impression that it should be
<manumanumanu>i never had any luck with eval-when, but that documentation really does seem to imply that that stores the compilation date in *compilation-date*
<manumanumanu>it clearly does not
<manumanumanu>neither at the repl, nor if run as a file.
<RhodiumToad>so the question is, how would one do that
<manumanumanu>syntax-case
<manumanumanu>and return the correct syntax object. simple
<manumanumanu>(datum->syntax #'stx (date))
<RhodiumToad>seems reasonable
<manumanumanu>We could probably even do rudimentary constexpr using syntax-local-binding
<manumanumanu>just error on anything else than 'global
<manumanumanu>lets not...
<manumanumanu>I am an idiot.
<manumanumanu>we need eval.
<manumanumanu>RhodiumToad: https://paste.debian.net/hidden/c5c3d5e4/ fails spectacularly if the thing cannot eval properly at compile time.
<manumanumanu>not spectacularly, but with an unknown variable and a world record backtrace
<manumanumanu>RhodiumToad: you need to quote the output, otherwise it fails on (list 1 2 3)
<manumanumanu>RhodiumToad: https://paste.debian.net/hidden/d861657a/
<matijja>Hello Guilers!
<matijja>How can I make global variable, which is shared per threads?
<RhodiumToad>you mean there's just one value that all threads see? that's the default case
<RhodiumToad>but you have to be aware of concurrency issues if you try and mutate it with multiple threads in play
<manumanumanu>matijja: if the variable is in scope when the threads are created, it will be visible to all threads. Mutating it will be problematic though. If you use parameters, any change to them will be thread local (I THINK). You can also use atomic boxes, or mutexes.
<RhodiumToad>parameters are fluids, which are thread-local (and respect dynamic scoping too)
<matijja>So, I may have another problem. I'm using parameter as global variable in package for storing all opened sockets. http://paste.debian.net/1164221
<RhodiumToad>that shouldn't be a parameter then
<RhodiumToad>that should probably be a hashtable or something
<matijja>Are parameters thread local?
<RhodiumToad>they are
<RhodiumToad>however, threads inherit the values of parameters from their creators
<RhodiumToad>changes are local to the changing thread (actually local to the dynamic scope)
<matijja>Ok. Ordinary lists works fine. Thanks for info.
<RhodiumToad>btw you can use (with-mutex ...) to execute forms with a mutex locked
<RhodiumToad>if you use lock-mutex directly, you have to think about what to do about errors
<RhodiumToad>whereas (with-mutex) will unlock in the event of a nonlocal exit (and relock in the event of a nonlocal entry)
<matijja>I didn't know that with-mutex already exists.
<manumanumanu>matijja: if you are mutating a list, you _need_ to use locks. guile is not like python. things execute in parallel :D
<RhodiumToad>you could prepend to a list without locking by using an atomic box to hold it, I guess?
<RhodiumToad>you'd need to use a compare-and-swap to update it and retry on failure
<matijja>manumanumanu: lock/unlock-mutex is there for that reason.
<matijja>And how atomic-box works without mutexes?
<RhodiumToad>using atomic update primitives, presumably
<RhodiumToad>the main thing about atomic boxes is that you can do a compare-and-swap - i.e. "if the value is currently X then replace it with Y, otherwise do nothing"
<RhodiumToad>(returning the old value in either case)
<RhodiumToad>and the comparison/swap is atomic with respect to other threads
<RhodiumToad>the advantage is not needing locking, the disadvantage is that you have to do your own retry logic for the case when some other thread gets in there first
<matijja>This should be used for more frequent operations I think.
<matijja>I doesn't expect an army of sockets...
<RhodiumToad>not sure why you're not using a hashtable though
<matijja>Because I don't need mapping. Maybe I could use hashmap as hashset.
<ArneBab>guile-wisp 1.0.3 is now in Guix: It ships a wisp binary that starts a Guile with wisp as language and can directly execute wisp files. Also it includes wisp2lisp which takes a wisp file and writes a plain Scheme file to stdout.
<civodul>ArneBab: yay, congrats!
<ArneBab>Thank you!
<ArneBab>my patch was merged (and cleaned up!) by rekado