dddddd has quit [Remote host closed the connection]
gabot has joined #racket
badkins_ has quit [Remote host closed the connection]
_whitelogger has joined #racket
<greghendershott>
lavaflow: One thing to keep in mind is that a parameter can have a different value in each thread.
<greghendershott>
When a thread is created, it will inherit the values of its parent thread.
<lavaflow>
ah, I'm not explicitly creating a new thread but maybe that's happening behind the scenes
<greghendershott>
But thereafter, it will not "see" changes made by other threads.
<lavaflow>
hmm okay, this shouldn't effect me then. I only use parameterize once, at the very beginning of my app right before I initilize the first window
<lavaflow>
I was afk for a few hours but now I'm going to see if I can create a minimum demonstration of this
<greghendershott>
You could try something like `(current-eventspace (make-eventspace)) (sqldb ___) (new frame% ___)` -- deliberately not using `parameterize` here -- and see if that works?
<greghendershott>
Or maybe put `sqldb` before `current-eventspace`.
<greghendershott>
I'm not really sure. And even if it works, then, not sure that's the right way to do it ultimately.
<lavaflow>
I'll try these, thanks
<greghendershott>
Just suggesting some empirical prodding to get a sense what might be happening.
<lavaflow>
aye
<greghendershott>
Alas it is midnight here and I have to run now. But good luck!
buyfn has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
ZombieChicken has quit [Ping timeout: 256 seconds]
mjanssen has quit [Remote host closed the connection]
mjanssen has joined #racket
mjanssen has quit [Remote host closed the connection]
mjanssen has joined #racket
pierpal has joined #racket
buyfn has joined #racket
buyfn has quit [Ping timeout: 245 seconds]
dddddd has joined #racket
iyzsong has joined #racket
hjek has joined #racket
<lavaflow>
okay new question unrelated to the previous mess: I've created this macro: (define-syntax macro-append (λ (stx) (datum->syntax stx (apply string-append (cdr (syntax->datum stx))))))
<lavaflow>
with the intent that (eq? (macro-append "foo" "bar") (macro-append "foo" "bar")) would return #t. but it actually returns #f
<hjek>
use equal?, no?
<hjek>
eq? is only true if they refer to same obj
<lavaflow>
well, yes. that's the real solution, but I'm trying to make a temporary work-around for a package (memo) that uses hasheq's instead of equal? hashes.
<hjek>
oh, ok, i entered during the middle of this thing. didn't get the context
<lavaflow>
I expected that macro to produce strings that were the same object. in Guile that's what it does (it works like I expected)
<lavaflow>
oh no sorry, I didn't provide context for thi
<hjek>
ok, this is way beyond what i can grasp, but my naive way of dealing with this would perhaps be to define a function that memoizes the returned objects, so if it get's the same input, it would fetch the object it already made
<hjek>
so, memoization?
<lavaflow>
My real usecase here is I'm (ab)using (string-append ...) to write multi-line string literals of sql queries, and am trying to memonize the preparing of those strings. So I'm using the memo package: (define/memoize (prepared sql) (prepare (sqldb) sql))
<lavaflow>
I could write my own memoization function that just uses hash-equal?, but I kind of like the memo package so I'm trying to use that instead of doing it myself
<hjek>
ok, it's beyond me :-)
<lavaflow>
I should probably just take the non-lazy approach and submit a PR to the `memo` author for using hash-equal?, and in the meantime just use my own version.
<lavaflow>
but I'm a bit curious if there is a way to make that macro work as intended in racket, since it works in guile. I'm guessing whether or not two string literals are actually eq? is very implementation dependant...
hjek has quit [Quit: Leaving.]
krono has joined #racket
jao has joined #racket
hjek has joined #racket
jcowan has joined #racket
dddddd has quit [Ping timeout: 252 seconds]
jao has quit [Ping timeout: 268 seconds]
dddddd has joined #racket
acarrico has joined #racket
tennix has quit [Ping timeout: 250 seconds]
confusedwanderer has joined #racket
Lowl3v3l has quit [Remote host closed the connection]
iyzsong has quit [Ping timeout: 276 seconds]
YuGiOhJCJ has joined #racket
gnugnugnu has joined #racket
tennix has joined #racket
badkins has joined #racket
rnmhdn has quit [Quit: WeeChat 2.3]
gnugnugnu has quit [Quit: WeeChat 2.3]
<lexi-lambda>
lavaflow: You could probably use datum-intern-literal to make the strings interned strings. But I agree that using equal?/hash-equal? is really the right thing here.
vraid has quit [Quit: Leaving]
<lavaflow>
part of me is thinking that eq? is a better approach just because some of these lookups are occuring in hot loops and the difference between equal? and eq? on large strings (well, hundreds of bytes..) might actually make a difference
<lavaflow>
but another part of me says I should get ride of those queries in tight loops anyway because that's just not a smart approach in the first place
<lavaflow>
thank you for the datum-intern-literal suggestion though.
tennix has quit [Ping timeout: 250 seconds]
<lexi-lambda>
It seems like maybe you should be using prepared statements?
<lexi-lambda>
Why are you re-preparing the statements lots of times? Shouldn’t you prepare each query once, then re-use the prepared statement?
<lavaflow>
it only prepares it once since it's memoized, but it looks up the prepared query in a hash over and over again just because I wanted to have the query string in the same place as I'm using the query
<lavaflow>
I'm sure there is a better way to do this
<rain1>
it sounds kind of interesting, if you put the code online i'd look at it
<lexi-lambda>
I feel like, if you’re so concerned about performance that you think eq? will make a measurable performance difference over equal?, you should avoid the table lookup entirely and just refer to the prepared statement directly. :)
<lavaflow>
when I switched to using prepared statements, wrapping all my statement strings with a memoizing (prepared ...) just sort of seemed like the laziest way to do it.
<lexi-lambda>
Depending on the details, you might be able to write a macro that uses syntax-local-lift-expression to lift preparation of a query to the top of the current module.
<lavaflow>
that sounds like a good idea. I need to give myself more macro exercise tbh.
<rain1>
what about expanding into something like this (define my-query (let ((prepared-bit <stuff>)) (lambda (db) send the prepared bit to the db)))
<lavaflow>
is using ghostbin frowned upon around here? I'd love to love pasterack.org but google catpcha is nigh impossible for me to get past these days.
<lavaflow>
in that example both (prepared ...) and (tag-id-lookup ...) are being memoized with the same macro, which is aesthetically pleasing to me and also a good thing because tag-id-lookup gets called way too often.
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<lavaflow>
I think the hash-equal? lookup on strings like that shouldn't be a problem if I clean up my (ab)use of queries in tight loops
tennix has joined #racket
<lexi-lambda>
At first glance, it doesn’t look like the memo package ever releases values it retains for memoization, and a cache without an eviction policy is effectively a memory leak.
<lavaflow>
yeah, I'm keeping that in mind
<lavaflow>
for most of what I'm doing it's not going to be a problem. the prepared query hash will never grow larger than a few dozen (right now I think it never grows larger than about a dozen, I have a single query that is algorithmicly generated but I'm currently not preparing that one and I don't think I will)
<lavaflow>
I do have one memoization hash that has the potential to grow to gigabytes in an extreme case, I'm probably going to add time-based eviction for that one.
<lexi-lambda>
Personally, I think that depending on the eq-ness of strings is wrong, or at least very confusing, and I think you should use some macro machinery (like the aforementioned syntax-local-lift-expression) to provide a stronger guarantee. But I suppose datum-intern-literal technically can work.
<lavaflow>
the more I think about it, the more I think both are probably premature optimization, or at least misguided optimization.
<lavaflow>
I have one particularly hot query and I could improve it dramatically by having it return multiple rows it anticipates will be called up next.
<rain1>
this seems to be a shorter (better) version of the paper
<capisce>
rain1: I think I've stumbled over that paper before, might give it another try, this stuff seems quite interesting
<rain1>
it is interesting!
rand__ has joined #racket
<hjek>
When using 'db' in Racket to insert a row in a table in a database that has an auto-incrementing key; how can I get the value of the key of the row that was just inserted?
<lavaflow>
"For SQLite, the value is the same as the result of the last_insert_rowid function—that is, the ROWID of the inserted row."
<hjek>
vraid: that's probably better to do it all in one query. i'm a bit new to SQL, but I image that if I do it in separate queries, I'll have to make sure those are done in one transaction
<vraid>
that should probably work. i'm not exactly an sql expert myself
<hjek>
lavaflow: nice!
<lavaflow>
it looks like (query connection stmt arg ...) returns a simple-result? if it did an insert, so I think that should get you what you're looking for
<hjek>
lavaflow: that looks like the best solution. right there in the docs
<hjek>
ah, so just the general `query` function.
<hjek>
yay!
<lavaflow>
vraid: with sqlite most operations are entered as SQL. like putting sqlite into mmap mode is done with "PRAGMA mmap_size=..." but it's an embedded DB so the C api is also in play. So you could also do: sqlite3_config(SQLITE_CONFIG_MMAP_SIZE,...)
<lavaflow>
(pragma being a sqlite extension of sql)
<hjek>
ok, with the structs in Racket, usually a value is retrieved by <struckt>-<key>, right?
<hjek>
but `simple-result-insert-id` is undefined when importing db
<hjek>
ah ok misunderstood
<hjek>
it's simple-result-info
<hjek>
oopsy :-)
<lavaflow>
yeah info is an alist
<lavaflow>
kind of weird
confusedwanderer has quit [Quit: confusedwanderer]
orivej has joined #racket
sleepnap has quit [Quit: Leaving.]
hjek has quit [Quit: Leaving.]
confusedwanderer has joined #racket
orivej has quit [Ping timeout: 252 seconds]
hjek has joined #racket
hjek has quit [Quit: Leaving.]
hjek has joined #racket
hjek has quit [Quit: Leaving.]
hjek has joined #racket
YuGiOhJCJ has joined #racket
hjek has quit [Client Quit]
hjek has joined #racket
hjek has quit [Quit: Leaving.]
hjek has joined #racket
hjek has quit [Quit: Leaving.]
confusedwanderer has left #racket [#racket]
YuGiOhJCJ has quit [Remote host closed the connection]
ubLIX has joined #racket
YuGiOhJCJ has joined #racket
rand__ has quit [Quit: leaving]
<lavaflow>
does anybody have any idea what might be going on here?
<lavaflow>
2018-11-23 12:51:41.333 racket[20822:1851050] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'deferredCurrentActivation already set when we got another deferred activate event'
<lavaflow>
I don't really have time to dig into this atm, but I've saved the full logs and might have time later today
<lavaflow>
it seems to happen when I try to interact with a GUI app that's frozen because it's blocked on something that's taking a while to compute. but it doesn't do this every time.
ZombieChicken has joined #racket
mahmudov has joined #racket
hjek has joined #racket
hjek has left #racket [#racket]
ubLIX has quit [Quit: ubLIX]
pierpal has quit [Ping timeout: 244 seconds]
ng0 has quit [Quit: Alexa, when is the end of world?]
shw has quit [Quit: shw]
krono has quit [Quit: Connection closed for inactivity]