
@sumit.chaturvedi has joined the channel

@xiaoyushuo0419 has joined the channel

Hello everyone, I was testing out whether c libraries are reloaded every time you hit run in DrRacket and found something surprising.
C Code : int x = 0;
void inc () {
x += 1;
}
I compiled this on macOS Big Sur (v 11.1) using: $ gcc -fpic -c test.c -o test.o
$ gcc --shared -o libtest.dylib test.o
Racket Code : #lang racket
(require ffi/unsafe)
(require ffi/unsafe/define)
(provide (all-defined-out))
(define test (ffi-lib "./libtest"))
(define-ffi-definer define-test test)
(define-test inc (_fun -> _void))
(define (x) (get-ffi-obj "x" test _int))
(println (x))
(inc)
(println (x))
When I repeated hit run in DrRacket, I found that the library isn’t reloaded, which I found surprising!
Output: 1. First Run : 0 1 2. Second Run : 2 3 3. Third Run : 4 5 I made sure that the program was stopped between repeated attempts. The only way to restore the exported object was to quit DrRacket and restart.
Is this a feature or a bug?

@shu—hung and @ryanc I see now, why syntax-local-lift-module-end-declaration
is the wrong tool - and why syntax-local-lift-expression
works fine in my situation.

As far as I know, that’s just the way shared libraries work - in general not just in Racket. So if you are experimenting with different versions of a C library, then write the code in DrRacket - but run it from the terminal.

The shared libraries become part of the DrRacket process - not just the individual program run inside DrRacket.

@sumit.chaturvedi This is the expected behavior. If instead you call (ffi-lib "./libtest" #:custodian (current-custodian))
, the library will be unloaded when you hit Run in DrRacket, but there are important memory management caveats: from the <https://docs.racket-lang.org/foreign/Loading_Foreign_Libraries.html#%28def._%28%28lib._ffi%2Funsafe..rkt%29._ffi-lib%29%29|docs for ffi-lib
>: > If custodian
is 'place
or a custodian, the library is unloaded when a custodian is shut down—either the given custodian or the place’s main custodian if custodian
is 'place
. When a library is unloaded, all references to the library become invalid. Supplying 'place
for custodian is consistent with finalization via https://docs.racket-lang.org/foreign/Allocation_and_Finalization.html\|ffi/unsafe/alloc but will not, for example, unload the library when hitting in the Run button in DrRacket. Supplying (current-custodian)
for custodian tends to unload the library for eagerly, but requires even more care to ensure that library references are not accessed after the library is unloaded. > If custodian
is #f
, the loaded library is associated with Racket (or DrRacket) for the duration of the process. Loading again with ffi-lib
, will not force a re-load of the corresponding library.

@jagen315 Thanks for the tip - maybe it is “new” :slightly_smiling_face:

That makes sense. Thank you :smile:

@philip.mcgrath Thanks for pointing this out :smile:. Making this change worked.

@mflatt I have just updated my copy of Racket source code. Running make as-is
or make
reports an error standard-module-name-resolver: collection not found
for module path: (lib "setup")
collection: "setup"
in collection directories:
/Users/phay/Library/Racket/8.1.0.5/collects
/Users/phay/code/racket2/racket/collects/

Is “/Users/phay/code/racket2” your Git checkout? Assuming so, does “/Users/phay/code/racket2/racket/collects/setup” exist?

Ouch. I forgot I renamed racket2 to racket. Where can I fix the collection directories?

Looks like the easiest solution is to rename it back to racket2

I’m not sure how you ended up with “racket2” wired into a path, but it may be from a configure
, in which case explicitly running configure
might solve the problem.

Long story, but my bad. I first clone Racket into the racket
directory. Then later on, I wanted to test the speed of clean build on this machine made in 2012. So I cloned the racket repo into the racket2
directory. After I got the number, since racket2
was newer, I deleted racket
and renamed racket2
to racket
. Everything worked fine until 10 minutes ago when I was trying to rebuild the updated source code .

Browsing the Pollen docs, and they mention that there are a few restrictions on the code in templates. I cannot find documentation anywhere on what those restrictions are: does anyone know of such docs/what are the restrictions?

Maybe it’s just the rules in 7.4?
https://docs.racket-lang.org/pollen/third-tutorial.html#%28part._tags-are-functions%29

That explains what tags are, but doesnt explain the template restrictions.

From 6.4: > “So a template is also a Pollen source file?” Not quite. More accurately, it’s a fragment of Pollen source that is completed by adding the X-expression that comes out of one of your source files. Because of this, there are a few extra limitations on the code you can put in a template, though with easy workarounds. >

It used to be that you couldn’t use require
in templates but that changed some time after. That might have been what he originally had in mind with that sentence but didn’t go back and update it later.

Removing --no-user
from the command didn’t change anything (which I didn’t think it should).

Is it “normal” that I can’t see my own package just after submitting it at https://pkgd.racket-lang.org/pkgn/create ? Will it show up after the index refresh or should I re-submit it?

I think there is a delay. I haven’t figured out the interval between updates.

In case it matters, I used “simple URL” to be able to enter a “git+https://” URL, which should be supported starting with Racket 8.1. ( https://github.com/racket/racket/issues/3747 )

I think the site said something about a rescan on Sunday. I don’t remember the mentioned time.
So I’ll wait until Monday or Tuesday to account for any timezone differences and then check if I can see my package.

@abraham has joined the channel

That should show up quickly but I wouldn’t be surprised if the server is not yet running 8.1