<dsmith-work>Zerock: If you get a request header, I think there is something in there. <dsmith-work>Zerock: And if you can get at the underlying socket, you can find out from that. <Zerock>Right, but does Artanis expose this in the API? <dsmith-work>Oh, forget the request header. I was thinking of something else. <bipt>i think it should be in the request-meta alist if you can get at the http request object somehow <dsmith-work>sneek: later tell nalaginrut How do you get the requests source ip address in Artanis? Zerock wants to know. <daviid`>calling guile-gnome-2 -c "blibli ... (exit ((lamda () 0)))" [guile-gnome-2 is a autool generated #!/bin/sh script that sets things to be able to import guile-gnome modules, then call exec guile"$@"] returns 127 and not 0, which causes me problems writing a guile-gnome-2.m4 macro <daviid`>to simply, capturing the results of the following respective expressions in a m4 file will give these values: <daviid`>guile-gnome-2 -c "(exit ((lambda () 0)))" > /dev/null 2>&1 => 127 <daviid`> guile -c "(exit ((lambda () 0)))" > /dev/null 2>&1 => 0 <daviid`>if anyone has the sh and exec knowledge, ping me... tx <sneek>Welcome back nalaginrut, you have 1 message. <sneek>nalaginrut, dsmith-work says: How do you get the requests source ip address in Artanis? Zerock wants to know. <nalaginrut>dsmith-work: It's easy, Nginx can pass the source IP with a new header X-Real-IP <nalaginrut>if no reverse-proxy, Artanis will use request-host <paroneayea>say I had wanted to define a hygenic macro with define-syntax-rule that had some values, but I needed to iterate over them <paroneayea>the pseudocode I was sure wouldn't work totally works <paroneayea>if I *do* want a specific variable name, accessible within the expanded form, in the macro <paroneayea>eg, if I want my macro to add a => function to the lexical scope of the macro-expanded function *paroneayea brain bends a bit trying to wrap around this <bipt>paroneayea, using syntax-case, you can create a "hygiene-breaking" identifier using datum->syntax, and bind it as a pattern variable using with-syntax <bipt>defspecial is a simple example of that, in (language elisp runtime) <bipt>that's about the only thing about syntax-case i know, since otherwise syntax-rules is good enough for me :) <wirrbel>If I were to build a linked-list like data structure with libguile in C, would I encode the pointers to the next element as SCM or as implementation-native c-struct-pointers? <wirrbel>I am not building a linked list (would use Scheme list for that) but something similar <wirrbel>i.e. struct lst { struct lst * next; ...} or struct lst { SCM next; } <wirrbel>I think the 2nd option might be necessary for GC ***michel_mno_afk is now known as michel_mno
<mark_weaver>please_help: as I've said before, this whole approach that builds lists of indices and increments that list on each iteration is guaranteed to be slow as molasses. <mark_weaver>if the inner loop increment does more than increment a single integer, you're doing too much there <mark_weaver>'array-ec' also looks like it has a rather lot to do on every iteration. <mark_weaver>can you create a temporary flattened view of the array, and iterate that one with a single integer index, for at least one of these two constructs? <mark_weaver>please_help: in 'array-ec', that entire inner 'let*' should go outside of the 'do-ec'. <mark_weaver>and maybe that first 'if' statement within the 'let*' as well <mark_weaver>I confess I haven't taken the time to fully grok this code, so maybe I'm making a mistake here. <please_help>mark_weaver, I AM making a temporary flattened view of the array now <please_help>the let* cannot go outside the do-ec because the variable name held in result is not bound before then <please_help>or well, I'm incrementing the index of the flat part of the array, to be exact <please_help>the construct will look like (ec-name (:generator generator-params ...) payload). Calls to (:generator generator-params ...). Array-ec being the ec-name, and :array may or may not be the :generator. <please_help>after the expansion, :generator creates binding, payload is inserted in the most inner let in the expansion, and ec-name has the value of the payload execution inside result. <please_help>(array-ec (:array e #2f32((0 1) (2 3))) e) ;=> payload is "value of e", so array-ec receives ... variable-name-for-e, which value is bound to "value of e" inside the do-ec <please_help>Also it uses lots of continuation magic so the binding changes in every "iteration" of do-ec <mark_weaver>first of all, I should mention that if the last operand to 'array-ec' is a complex expression, then that complex expression will be duplicated in many places here. <mark_weaver>if you want to evaluate it just once and bind its result to a variable, you have to do that explicitly yourself <please_help>It will expand to the expression of payload only once <mark_weaver>'result' is used in many places in the template of 'array-ec' <please_help>result is only the name of the variable, so it will evaluate to "e", maybe another example will be clearer <mark_weaver>that is true if and only if you always pass a simple variable as the last operand to 'array-ec'. <please_help>(array-ec (:array e #2f32((0 1) (2 3))) (/ (1+ (exp e)))) ;=> payload is "(/ (1+ (exp e)))" so array-ec receives ... e, which value is bound to "value of e" <please_help>(array-ec (:array e #2f32((0 1) (2 3))) (/ (1+ (exp e)))) ;=> payload is "(/ (1+ (exp e)))" so array-ec receives ... magical-variable-name, which is going to be set by (let ((magic-variable-name (payload e))) ...) <mark_weaver>the pattern variable 'result' is bound to '(/ (1+ (exp e)))' in your example, and so that piece of code is substituted for each use of 'result' in the template. <mark_weaver>trust me that I know our macro expander rather well. <mark_weaver>if you want to evaluate it just once and bind the result to a variable, you need to do that yourself within the template with something like (let ((var result)) ...) <please_help>But then if you look in the srfi-42 document at :do, it shows that there is only 1 payload in the expansion <please_help>but we don't want to evaluate it once, we want to evaluate it once per binding <mark_weaver>it's true that uses of the generators get translated by srfi-42 before reaching the macros that you write. <please_help>array-ec doesn't actually know about the payload form does it? <please_help>I don't understand what you mean by payload being duplicated <please_help>:array expands to :do which only has one expansion with payload <please_help>that is assuming tha'ts what you're referring to by "the last operand to 'array-ec'" <mark_weaver>that might be, but I'm not talking about :array, I'm talking about array-ec. <mark_weaver>I realize that there's magic going on between the :array form that you write and what your :array macro actually sees. <mark_weaver>your 'array-ec' macro sees exactly what you write in your 'array-ec' form. <please_help>actually the expression is being duplicated, it's the variable that's not bound yet <mark_weaver>I would rename the pattern variable from 'result' to something like 'expr' or 'inner-expr'. <mark_weaver>and then add (result inner-expr) to your inner 'let*' <mark_weaver>although a lot more would have to be done to make this efficient, but that would at least solve that one issue. <please_help>so then, am I still doing something wrong with the indices? I am flattening the first K dimensions and doing +1 to the integer index now, are you referring to something else? <mark_weaver>well, for starters, you need to somehow simplify things in the innermost loops <mark_weaver>the innermost loop needs to know that it's the innermost loop at compile time. <mark_weaver>this is a huge amount of code that you are running on every iteration. that huge 'let*' <mark_weaver>lots of allocations, calls to higher-order procedures, etc. <mark_weaver>you need to radically simplify this for the inner loops. <mark_weaver>if you really need this construct to not know the rank at compile-time, then perhaps what you ought to do is create specialized versions of this loop for rank 1 and rank 2, at least, and then dispatch to one of those specialized procedures at the beginning of your loop. <please_help>if I could remove this, I could put everything outside the loop <mark_weaver>and you could use macros to create those specialized procedures <mark_weaver>so you wouldn't have to write them by hand. just write a macro that creates code that will optimize to something good, then use those macros to instantiate for a few low ranks, and then dispatch to them when you can. <please_help>Actually, I think I can make the assumption the rank of every result is the same <mark_weaver>please_help: is 'shape' the shape of the returned array? <please_help>with the assumption, we win an additional 10 seconds <please_help>mark_weaver: we know the shape of ret, not of result <please_help>that is, shape is the shape of the final array to return, not of the array which payload returns <mark_weaver>I guess I don't see why we should care what rank the payload returns. I think all I need to care about in 'array-ec' is the rank of the array it will return. <please_help>because I want to be able to remake arrays from array-parts <please_help>similar to, with numpy, numpy.array([numpy.array([exp(x) for x in e]) for e in full_array]) <mark_weaver>ah, so the shape is a prefix of the shape of the array you're working on, more generally? <please_help>so I have an array of array, but I really want to have one full 2d array <please_help>if shape is (20 20), I generally expect to generate 20 results from payload, each of shape (20) <mark_weaver>please_help: if you assume that rank of every result is the same, that enables us to cut out a lot of this code. <mark_weaver>please_help: in that 'let*', the only uses of 'result' are (array? result) and (array-rank result) <mark_weaver>so this entire 'let*' can be bound just after the first evaluation of 'result' <please_help>yes, that's what I'm doing now (which gave us 10s extra) <please_help>I do the bindings outside the let*, then change the let* for some set! if the bindings are not currently #f <please_help>I added the current code as an annotation to the same paste <mark_weaver>please_help: in (let ((expr result)) ...) those names are reversed. it should be (let ((result expr)) ...) and the code adjusted accordingly. the pattern variable holds the expression, so it should be called 'expr', and the normal variable bound by 'let' will contain the result, so it should be called 'result'. <mark_weaver>please_help: can you assume that for every result, (array-dimensions result) is the same? <daviid`>by the way it's called guile-gnome-2.m4 and only works for gnome-2 because that version is hard coded at guile-gnome build time and there is no way [till now] to know it, the gnome-2.scm has this -2, as well as all guile-gnome-*.pc files ... but may be later i can change the build process of guile-gnome so that it's generalized... this was not the quiz :) <daviid`>the quiz is related to GUILE_GNOME_CHECK, line 145, you see i had to comment $GUILE_GNOME -c ... in favor of the subsequent line. this is because the values returned by guile-gnome-2 [the aut generated script which i paste in a second] does not return the values returned by guile <daviid`>the problem is that script returns guile's [exit] values + 127 [if not mistaken, so always fails ... is there something we could do? <daviid`>please_help: ok, i used AC_MSG_RESULT($$1) to check what was wrong and for 0 it prints 127 <daviid`>the prob is i'm not very knowledgeable wrt /bin/sh mixed with exec ... <mark_weaver>that 'exec' is analogous to a tail-call in Scheme, a GOTO with arguments <mark_weaver>so guile returns directly to the caller of 'guile-guile-2' <daviid`>mark_weaver: really? it does not here, wonder why, let me prepare a paste of both cases <mark_weaver>In POSIX, 'exec' *replaces* the current process with a new one, in this case with a 'guile' process. The new 'guile' has the same Process ID as the bash that was previously running the 'guile-gnome-2' script <mark_weaver>actually, in a sense the process itself is preserved, not replaced <mark_weaver>but the program that's running within the process is replaced <mark_weaver>file descriptors are inherited though, and some other things <daviid`>[ and uncommented the line 169 to print the results... ] <daviid`>mark_weaver: it took me quite a while to track that problem, because i was sure andy did the right thing and never had a doubt about guile-gnome-2 returning guile's exit values, so looked for ome eror n my code... <daviid`>mark_weaver: config.log says the same as my trace: <daviid`>configure:2924: checking if (gnome gnome) is available\\nconfigure:2932: result: 127\\nconfigure:2935: result: no\\nconfigure:2940: error: required guile-gnome module not found: (gnome gnome) <mark_weaver>daviid`: have you tried changing "$2" to "(use-modules (gnome-2)) $2" on line 147 of the .m4 file? <mark_weaver>I don't see anything in the guile-gnome-2 script that would cause the module to be automatically loaded <mark_weaver>another possibility is that the changes to GUILE_LOAD_PATH in the script are causing problems somehow <daviid`>mark_weaver: that module is not required for guile-gnome-2, precisly the 2 way to sets things so guile finds guile-gnome modules <daviid`>when running guile-gnome-2, from the .m4, is GUILE_LOAD_PATH visible to the m4 code ? <mark_weaver>the m4 is being used to generate a shell script that will later be run <mark_weaver>what do you think is the problem? I don't understand <mark_weaver>m4 is a preprocessor, not wholly unlike the C preprocessor <daviid`>mark_weaver: the problem is guile-gnome-2 sets the path so guile finds (gnome ...) modules. tht does not work for m4, as you just pointed out, so GUILE_GNOME_CHECK always fails. <mark_weaver>the m4 file contains code that m4 will merely copy into the resulting configure script, and 'guile-gnome-2' doesn't get run until later <mark_weaver>'guile-gnome-2' will not be run until the user runs ./configure, which is long after 'm4' finished <mark_weaver>people who compile from release tarballs don't even need 'm4' typically, because they just run the script that 'm4' produced <daviid`>i got that, but configure, even running guile-gnome-2, does not re-read its env vars, obviously, so it will alwaus fail anyway <mark_weaver>I don't understand what you mean by "re-read its env vars" <mark_weaver>we have a case that works, and a case that doesn't work, depending on whether you use lines 146-147 or 148-149 <mark_weaver>these are the differences I see between those two cases: <mark_weaver>(1) for one, you insert (use-modules (gnome-2)), and in the other you don't <mark_weaver>and (2) in one case the 'guile-gnome-2' script is augmenting the values of GUILE_LOAD_PATH and LD_LIBRARY_PATH before running guile <mark_weaver>to debug this, the appropriate next time is to determine which of those two differences is causing the failure <mark_weaver>I see no reason to include (use-module (gnome-2)) and not the other <mark_weaver>either it should be needed for both, or needed for neither. <daviid`>mark_weaver: that's not correct, at least in a normal guile-gnome app script: there are 2 equivalent ways to start a guile-gnome app. in this m4/configure 'schema', things appears different, because what guile-gnome-2 does [and does well] for a user script which will start the app], does not work for configure <daviid`>'equivalent' from the usser point of view. <daviid`>but from what yu said, i can add (use-module (gnome-2)) in the m4 files, no arm anyway and it will work <daviid`>and it is not working! weird! I changed the line for this: $GUILE-GNOME -c "(use-modules (gnome-2)) $2" > /dev/null 2>&1 but still fails there must be something else going on <mark_weaver>that 'localpath' thing in 'guile-gnome-2' looks very fishy <mark_weaver>daviid`: did you rerun 'autogen.sh' and 'configure' after making that change? <mark_weaver>so you have -c "(use-modules (gnome-2)) $2" in both places now? <daviid`>the 1st way does not work from within configure [if that makes sence?] <daviid`>not fully sure yet, but it seems that the guile-gnome-2 script alwys returns 127, not mtter what <daviid`>mark_weaver: so, here at least, guile-gnome-2 script does not return what guile returns, why is that if you say it should ? any mising sh magic like 'exit exec guile ...' [just shooting in the dark <daviid`>something in the guile-gnome-2 script 'corrupts' the results if i mat say so, but what ? <daviid`>mark_weaver: if i call, in AC_DEFUN([GUILE_GNOME_CHECK], ... /opt/bin/guile-gnome-2 -c "$2" > /dev/null 2>&1 ...]) instead of $GUILE-GNOME -c "$2" > /dev/null 2>&1, then i get the expected results <daviid`>that's the weirdest thing i've seen in years :) and now what? i'm idea less <daviid`>why does this works: $GUILE -c "(use-modules (gnome-2)) $2" > /dev/null 2>&1, this as well: /opt/bin/guile-gnome-2 -c "$2" > /dev/null 2>&1, but not this $GUILE-GNOME -c "$2" > /dev/null 2>&1 even though $GUILE-GNOME is bound to /opt/bin/guile-gnome-2 ?? <daviid`>please_help: right, hours i'm looking to the code and did not spot that! tx!! what a stupid tipo !! <daviid`>oh man , reading our own code is really bad :) i did see _ for hours :):) <daviid`>great, guile-gnome-2.m4 is ready! [and does not depend upon guile.m4, which would not be that bad, but that's what i wanted] <daviid`>please_help: it is fortunate that i did ask copying the guile-gnome-2.m4 code line, becausse if i did write 'manually' istead, chances ae that i would have written $GUILE_GNOME ...