pocmatos
2020-6-3 09:54:40

@notjack desperate measure to warm up your room?


sorawee
2020-6-3 10:37:36

@notjack

#lang racket (require package-analysis pkg/lib) (define raco "/Applications/Racket v7.7/bin/raco") (define all-pkgs (set-subtract (for/list ([x (get-all-packages)]) (package-details-name x)) (append (installed-pkg-names #:scope 'installation) (installed-pkg-names #:scope 'user)))) (apply system* raco "pkg" "install" "--auto" all-pkgs)


sorawee
2020-6-3 10:38:41

If your computer flies, don’t blame me!


spdegabrielle
2020-6-3 11:12:06

:fire::computer:


soegaard2
2020-6-3 12:20:05

The first version of flomat (floating point matrices) is now available at the package server. The documentation is here: https://docs.racket-lang.org/manual-flomat/index.html Please report mistakes of any kind including grammar, spelling, and, typographical mistakes.

The expectation is that flomat works on both macOS and Linux without having to install anything but the package sci. That is, CBLAS and LAPACK are now distributed with the Linux version.

Are there any obvious functions missing?


sorawee
2020-6-3 12:31:49

There seems to be a dependency problem: https://pkg-build.racket-lang.org/server/built/deps/sci.txt


soegaard2
2020-6-3 12:32:14

Yes - I have committed fix for that.


sorawee
2020-6-3 12:32:24

Also, I’m surprised that you didn’t use defproc, which makes code not linkable


soegaard2
2020-6-3 12:33:16

I’ll use defproc in the reference section. For now the QuickStart Tutorial will do.


soegaard2
2020-6-3 12:33:41

The QuickStart tutorial got a little long though…


ben
2020-6-3 13:04:48

thanks for the second opinion


notjack
2020-6-3 18:44:00

@pocmatos @sorawee someone in the Racket discord wanted a way to get a local copy of the whole catalog because they tend to be without internet for very long stretches of time


mflatt
2020-6-3 18:52:01

raco pkg catalog-archive


laurent.orseau
2020-6-3 19:28:18

It says package: sci. Is that normal?


soegaard2
2020-6-3 19:39:48

Yes. I hope add sci/poly (polynomials) besides sci/flomat at some point.


pavpanchekha
2020-6-3 22:03:29

I’m getting unusual results in the FFI when I’ve got a cstruct containing strings


mflatt
2020-6-3 22:04:10

Are you receiving strings through a struct or sending them?


pavpanchekha
2020-6-3 22:04:12

Should I declare the mode 'non-atomic?


pavpanchekha
2020-6-3 22:04:25

I create the struct Racket-side and send it to Rust


pavpanchekha
2020-6-3 22:04:38

sometimes instead of valid strings Rust sees garbage


mflatt
2020-6-3 22:04:56

That’s difficult to get right. Using 'non-atomic could work for BC, but not CS.


mflatt
2020-6-3 22:05:20

Do you need the strings to be GCed, or is there an obvious point to free them?


pavpanchekha
2020-6-3 22:05:56

There’s an obvious point to free them


pavpanchekha
2020-6-3 22:06:01

Should I manage memory by hand?


pavpanchekha
2020-6-3 22:06:05

It’s pretty easy in this case


mflatt
2020-6-3 22:06:08

Yes, that’s the easiest way.


pavpanchekha
2020-6-3 22:06:14

nice ok


pavpanchekha
2020-6-3 22:33:06

If I have a define-cstruct FFIObj with #:malloc-mode 'raw, is that also how fields of the struct will be allocated? When auto-converted?


mflatt
2020-6-3 22:34:12

No. You’ll have to explicitly allocate the strings individually.


pavpanchekha
2020-6-3 22:35:21

thanks


pavpanchekha
2020-6-3 22:41:17

Actually I might need more help with the mechanics here


pavpanchekha
2020-6-3 22:41:47

I’ve got a Racket string; how do I 1) convert it to a _string/utf-8 and 2) how do I pass the resulting pointer to the struct?


lexi.lambda
2020-6-3 22:42:33

@mflatt I am trying to understand what is going on with alignment of picts. I wrote this small program as a demonstration: #lang racket (require pict) (define (make-example inset-amount) (scale (cc-superimpose (disk 4 #:color "white" #:border-width 1) (colorize (linewidth 0.5 (vline 0 5)) "gray") (inset (colorize (linewidth 0.5 (hline 5 0)) "gray") 0 0 inset-amount inset-amount)) 100)) (define p (inset (hc-append 100 (make-example 0) (make-example 0.001)) 100)) (define bmp (pict->bitmap p 'smoothed)) (send bmp save-file "/tmp/example.png" 'png) It draws two disks with lines superimposed on top. For the second disk, the horizontal line is inset by 0.001, which I would not expect to have a significant impact on the result. And yet, this is the output I get.


lexi.lambda
2020-6-3 22:44:08

I don’t understand: 1. Why, in the left image, aren’t the lines centered on the disk? 2. Why, in the right image, does a tiny offset cause the line to be horizontally centered but even more vertically off-center?


pavpanchekha
2020-6-3 22:45:28

Ah, bytes are pointers


lexi.lambda
2020-6-3 22:45:31

I have peeked at the implementation of some of these functions, and it appears to use a quotient* function in places, which has this definition: (define (quotient* a b) (if (integer? a) (quotient a b) (/ a b))) This seems suspect to me, and I don’t understand its purpose, but maybe I am missing something.


lexi.lambda
2020-6-3 22:54:14

…it looks like if I replace the definition of quotient* with (define quotient* /), then I do, indeed, get the output I want: correctly aligned picts in both cases.


mflatt
2020-6-3 22:56:08

Yes, I think cc-superimpose is trying to align to unit sizes, and scaling after that scales up the alignment


lexi.lambda
2020-6-3 22:58:04

Yes, that seems right—but that’s sort of weird, isn’t it? It doesn’t work if things scale up, and I thought the 'aligned smoothing mode was supposed to handle that in a neater way.


mflatt
2020-6-3 22:58:56

It’s from the bad old days when scaling didn’t work on anything. The pict library started out as a front end for Latex…


mflatt
2020-6-3 22:59:25

I’m not sure how to get from there to here, but it certainly seems worth looking for a path


lexi.lambda
2020-6-3 23:00:10

Haha, well, don’t let me bring up old trauma! :smile: But yes, I would like that. Do you think just making the change would be too aggressive? I’ve been trying to imagine what it might break.


lexi.lambda
2020-6-3 23:01:05

The conservative option I considered was to introduce a parameter like current-pict-alignment-mode or something like that, which is a bit awkward but would preserve the existing behavior.


mflatt
2020-6-3 23:01:57

It’s tempting to just change it. I’ll try it and see what happens to various slide decks


lexi.lambda
2020-6-3 23:02:48

That’s a good idea. I can try that, too, on the few I have lying around.


samdphillips
2020-6-3 23:05:24

> parameter like current-pict-alignment-mode values 'old-and-broken


lexi.lambda
2020-6-3 23:12:55

I thought I had spotted a little bit of weirdness in my most recent slide deck, but I checked, and it seems equally misaligned both with and without the change, so I’m not sure what’s going on there. Maybe 'aligned is biting me in that case. Otherwise I haven’t really noticed any differences.


mflatt
2020-6-3 23:16:35

I can’t see a difference either, not that I really expected anything.

I can confirm by rendering to PS and diffing that lots has shifted by a small amount. The diff is full of things like 78971c78886 < -306.801 432.458 m -310.801 426.059 l -306.801 427.66 l -303.602 426.059 --- > -307.602 432.458 m -310.801 426.059 l -307.602 427.66 l -304.398 426.059 For an 80k-line .ps file, the diff is 20k lines, so something like 10–15% of the drawing shifted. Again, not surprising.


lexi.lambda
2020-6-3 23:23:00

There are a couple other small places with calls to floor or remainder that seem likely to be similarly broken, most significantly in dash-line, but otherwise it seems like most places just use quotient*.


lexi.lambda
2020-6-3 23:27:01

Also, it doesn’t look like 'aligned was causing my other misalignment, so I’m not sure what’s happening there, but text is involved in that case, so it’s probably something else entirely (and probably a lot more complicated :grimacing:).


lexi.lambda
2020-6-3 23:32:42

@mflatt Would you like me to open a PR, or would you rather just make the change yourself?


mflatt
2020-6-3 23:37:21

I’ll submit a PR to make sure we have the same changes in mind.


lexi.lambda
2020-6-3 23:44:10

Alright, that sounds good.


leif
2020-6-4 02:04:02

@jbclements You latest commit for portaudio broke it for linux


leif
2020-6-4 02:04:10

callbacks.sodoes not exist.


ibrahimadam193
2020-6-4 03:48:52

Oh! Thank you, I’ll try this tonight.


ibrahimadam193
2020-6-4 04:12:41

It works! I wish they accepted the pull request.


sorawee
2020-6-4 05:23:28

The PR still needs some polishing, but it’s close to mergable


ibrahimadam193
2020-6-4 05:30:22

It looked like it was pretty close. I saw the last action taken on it was halfway through January.


ibrahimadam193
2020-6-4 05:31:14

Well, I wouldn’t know how close it was. Just that there was a decent amount of back-and-forth.