IRC channel logs


back to list of logs

<mwette> /quit
***Aurora_iz_kosmos is now known as Aurora_v_kosmose
<dustyweb>pkill9: hm, I haven't actually demonstrated it anywhere in my own stuff... I've been putting tags in the markdown files but not actually exposing them
<dustyweb>so... not really :)
<dustyweb>but I know Haunt does recognize them
<chrislck>are the mingw hackers targetting mingw-w64 by any chance?
<spk121>chrislck: there's a patch on guile-devel we're working on for mingw-64. If you want to see how it is going, or try it out
<janneke>spk121: i can't find a link to it, but wingo suggested instead of
<janneke>> 813 - unsigned long bit_count;
<janneke>> 813 + scm_t_unum bit_count;
<janneke>in arrays.c, to use [s]size_t (and not uintptr_t)
<janneke>which makes sense, i think
<janneke>while doing such a big change, iwbn to get it right, and not have to change it again ;-)
<fnstudio>hi, i'm taking the first steps into the world of design for flexibility and i have a question around "(lambda (args) ..." vs "(lambda args ..."
<fnstudio>minimum example: (it's a simple example, no spoiler alert needed with regard to the book's exercises)
<fnstudio>i suppose that "lambda args" may be preferred in so far it gives more flexibility with regard to the number of arguments? whereas with "(args)" then args has to be exactly one value?
<stis>Hi guilers!
<rekado>fnstudio: yes, (lambda (args) …) requires exactly one value, wherease (lambda args …) binds the argument list (even if it is empty) to “args”.
<fnstudio>rekado: i see... thanks, yes i think i can see it more clearly now, and "args" probably makes things a bit easier down the line
<fnstudio>also explained very well here:
<fnstudio>"formals" can be "(arg1 ...)", "args", or "(arg1 ... argn . argn+1)"
<spk121>janneke: yeah, size_t there makes sense,. That's what that array macro returns
<janneke>i'll change that
<janneke>spk121: but now i'm wondering about the laest: scm_i_inum => intptr_t, unsigned long long => uintptr_t
<janneke>shall we use size_t and ssize_t instead?
<spk121>what are your thoughts?
<spk121>If one were to try to take advantage of the implied meaning of the C types, intptr_t would be held specifically for integers that might contain pointers, while size_t would be only for indicating the memory size or count of things.
<janneke>ah, yes -- seen that way, intptr_t makes more sense
<spk121>For those things that were neither integers-holding-pointers, nor the memory size of things, it should really be long, long long, int64_t, or whatever
<spk121>Theoretically, if we
<janneke>yes, i agree
<spk121>have disambiguated everything into int-holding-pointer, size, or "regular" integer, it should not be a problem to keep the "regular integer" longs in most cases. It is just that, from my point of view, doing that disambiguation is rather tricky
<janneke>changing some intptr_t back to long is going to be somewhat tricky, we'd have to be very careful not to truncate on mingw 64bit
<spk121>For 32-bit platforms, those longs do work. I still build guile on at least one 32-bit platform. It is the truncation of integers that is a problem, as you say
<spk121>Can we get a compiler to do the hard work of detecting improper casts of integer size? Some combination of warning flags?
<leoprikler>w.r.t. cross-compiling Guile libraries, how does detection of $(host) work?
<leoprikler>i.e. for guild compile --target
<janneke>in an autoconf setup, configure just picks up --host
<janneke>then you do something like
<janneke>if test "$cross_compiling" != no; then
<janneke> GUILE_TARGET="--target=$host_alias"
<janneke>and use something like guild compile $(GUILE_TARGET) ...
<spk121>janneke: so here I am digging into gcc options, and I came across one called "-mlong64" which forces longs to be 64 bits
<janneke>spk121: that's interesting...
<leoprikler>hmm, I just figured, I'd always get $(host) set if I use AC_CANONICAL_HOST
<janneke>regtur asked me about that, and i dismissed him saying that all system headers/libraries would be incompatible with the rest of mingw/windows then, but...
<leoprikler>just compile all of it with -mlong64 and it's fine :)
<leoprikler>inb4 short long
<leoprikler>alias long short
<janneke>yeah, it may just work
<janneke>but makes you wonder, if there's such an easy and obvious solution, why would gcc not have that option on by default
<spk121>doh! Looks like it is MIPS only
<janneke>there surly must be a strong case (use case) for th long=4bytes thing
<janneke>yeah, i mean it's extra work for the gcc folks to make long=4bytes on mingw
<tohoyn>janneke, leoprikler: may be you should see dpkg-architecture
<janneke>they cant' be all totally mad?
<leoprikler>I think "long"=32 bits is historical, since back then int=16 bits
<spk121>32-bit long will still be allowed by the upcoming C23 standards
<janneke>leoprikler: yes, you can probably use --target=$(host)
<leoprikler>Well, the C++ committee can't really single-handedly decide Microsoft to be stupid, when Microsoft sits in the committee :)
<leoprikler>would be funny if someone invented a programming language, where all data types are just bit fields of size 2^N.
<leoprikler>N defaults to 32 and you double it by declaring something "long" and halve it by declaring it "short".
<leoprikler>but you have to declare at least one :)
<leoprikler>so to have a default int you'd have to write "long short foo"
*janneke puts up arrays.c change for wingo, also mailing v3
<fnstudio>hi, is there any particular channel that's being used for discussing and "socialising around" the new book "software design for flexibility"?
<spk121>ok, new plan. Let's re-write Guile in ADA.
<janneke>oh great! be sure to also write an ADA compiler that can be bootstrapped, so that we can have the new Guile in Guix ;)
<spk121>no problem!
<fnstudio>what's the difference between define and let when locally defining a procedure within another one, eg in this example
<fnstudio>i thought i have some background on what the difference is, at a general level
<fnstudio>but then i found a snippet where "define" is used where i'd have used a "let" instead
<leoprikler>local defines are equivalent to letrec with less indentation
<fnstudio>leoprikler: oh ok, great, thanks, so no differences in terms of scope for instance, etc; would it be sensible to say that one is syntactic sugar for the other?
<leoprikler>pretty much, yeah
<leoprikler>if you observe anything else, that's a bug
<fnstudio>leoprikler: i see, fantastic, tx!
<fnstudio>(oh today i learned mit/gnu scheme is not guile, how naive of me)
<roptat>any idea where this comes from? It seems to be copied from project to project, but there's no copyright/license information:
<leoprikler>reverse git search ;P
<civodul>roptat: probably from 'am/guilec' in Guile
<civodul>there's little originality in this file though (the main criterion to decide whether it's copyrightable)
<roptat>ah right, I recognize some of it, slightly modified
<roptat>I just watched the talk about reuse this morning at libreplanet, and they were copyrighting even .gitignore
<rlb>Right now a "shared" string has a start index, and that start index has to be added to the underlying shared string's index to compute the real offset in the underlying buffer, but can those indexes (offsets) ever change? If not, I thought I might just add them when creating the shared string, so we don't have to repeat the computation all the time. i.e. shared strings would have an absolute index into the (indirectly) underlying
*stis is improving the guile python repository. Bug after bug after bug ....
*janneke may have fixed the "Fix 'absolute-file-name?' and others..."
<spk121>I'm not sold on the idea that we have different 32-bit and 64-bit representations of a hash. (actually 30 and 62 bit). Either 30 bits is enough, or it isn't
<RhodiumToad>it usually isn't
<janneke>i wondered about that too
<janneke>i tried without patchin hash.c, but that "didn't work"
<janneke>i figured that it may have to do with the sizes of fixnum having to be equal to the hash size, for some reason, but i don't know
<janneke>it's "interesting" that "long" was used before, and not "int", if 30 bits are always ok?
<spk121>anyway, when guessing semantic meaning to the various integers in Guile that appear in your patch, one big category is 'hash value' which apparently needs to be scm_t_inum sized. It is inum sized when created by JENKINS_LOOKUP3_HASHWORD2
<spk121>or rather it is *intended* to be scm_t_inum sized, but is actually unsigned long size when passed around
<janneke>hmm; it has this
<janneke>if (sizeof (ret) == 8) ret = (((uintptr_t) c) << 32) | b;
<janneke>and if there isn't uintptr_t, but long, shift is problematic
<janneke>but possibly we can change the caller, i.e. "ret"?
<janneke>hmm, that's only narrow_string_hash and wide_string_hash
<janneke>and it's a whole chain...
<janneke>could it be that (something like) this:
<janneke> case scm_tc7_pointer:
<janneke> return scm_raw_ihashq ((uintptr_t) SCM_POINTER_VALUE (obj));
<janneke>is why we need the hash bits to be pointer-sized?
<spk121>I think, for symbols, it is because it gets packed into an scm_t_bits size word in scm_double_cell in scm_i_make_symbol
<spk121>for scm_tc7_symbol
<janneke>ah, that makes sense
<spk121>So there are two hashers. JENKINS for string-like things, scm_raw_ihashq for everything else. Both return unsigned long intending to an scm_t_inum
<spk121>I think, just for fun, I'll see what happens if I make an scm_t_hashval type and trace it through the code
<janneke>that's great, thanks for looking into this!
<wingo>haha, just realized that all the tree-il accessors are procedures-with-setters
<wingo>that's special :)
<wingo>hooo, it seems that the accessors also don't check the type of their operand
<janneke>initially, mes didn't check anything, not even the if the parameter count to procedures matched
<janneke>i would test everything by running it on guile anyway, right?
<janneke>that was one on the worst decisions and it cost me a lot of time until i corrected that ;-)
<spk121>fun fact. in weak-table.c, hash values are converted to buckets by using modulo. In cache-internal.h hash values are converted to buckets by using a mask of the low bits
*wingo writes a tree-il codec
<wingo>yaaargh, i managed to unify three record type representations in guile (conditions, r6rs records, core records) but not (system base syntax) records
<wingo>ah no it's that the "core vtables" mechanism doesn't produce vtables of the right shape...
<rlb>wingo: and goops instances?
*rlb still hopes to unify records and class instances wrt method specializations.
<wingo>goops instances are not unified right now
<rlb>progress at least, perhaps.
<rlb>I imagine we're not changing the long/intptr_t/etc. stuff in any public apis, or that'll just go into 3.2 or 4.0?
<wingo>yeah at least going in the right direction. goops is so peculiar that it would be nice if it could somehow absorb records -- i.e. treat a record type as a class in all places -- but without forcing the class representation down into core records. but i don't know what would be needed.
<wingo>rlb: yeah exactly
<janneke>no public apis are changed
<rlb>wrt classes, yeah, I'm not very knowledgeable there yet, just mostly experienced that bit from the end-user perspective.
<janneke>i believe i saw a patch that added keyword parameters to methods, any ideas where that might be or who wrote that?
***Noisytoot is now known as LPBot_
***LPBot_ is now known as Noisytoot
<janneke>spk121: just a heads-up, my latest patch doesn't compile on mingw, mini-gmp.c needs to include stdint.h explicitly
*janneke pushes a fix and starts another guile-patched,guile-mingw build
<janneke>fun, i was attempting to test my absolute-file-name? fix
<spk121>janneke: sadly, I've run out of time for this for now, but, I've learned a lot about guile's hashes and hash tables today
<janneke>spk121: while it would be nice to have this in 3.0.6, i'm not at all in any hurry
<janneke>thanks a lot for looking into this, there is time
*janneke -> zZzz