@notjack desperate measure to warm up your room?
@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)
If your computer flies, don’t blame me!
:fire::computer:
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?
There seems to be a dependency problem: https://pkg-build.racket-lang.org/server/built/deps/sci.txt
Yes - I have committed fix for that.
Also, I’m surprised that you didn’t use defproc
, which makes code not linkable
I’ll use defproc
in the reference section. For now the QuickStart Tutorial will do.
The QuickStart tutorial got a little long though…
thanks for the second opinion
@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
raco pkg catalog-archive
It says package: sci. Is that normal?
Yes. I hope add sci/poly
(polynomials) besides sci/flomat
at some point.
I’m getting unusual results in the FFI when I’ve got a cstruct containing strings
Are you receiving strings through a struct or sending them?
Should I declare the mode 'non-atomic
?
I create the struct Racket-side and send it to Rust
sometimes instead of valid strings Rust sees garbage
That’s difficult to get right. Using 'non-atomic
could work for BC, but not CS.
Do you need the strings to be GCed, or is there an obvious point to free them?
There’s an obvious point to free them
Should I manage memory by hand?
It’s pretty easy in this case
Yes, that’s the easiest way.
nice ok
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?
No. You’ll have to explicitly allocate the strings individually.
thanks
Actually I might need more help with the mechanics here
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?
@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.
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?
Ah, bytes are pointers
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.
…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.
Yes, I think cc-superimpose
is trying to align to unit sizes, and scaling after that scales up the alignment
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.
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…
I’m not sure how to get from there to here, but it certainly seems worth looking for a path
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.
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.
It’s tempting to just change it. I’ll try it and see what happens to various slide decks
That’s a good idea. I can try that, too, on the few I have lying around.
> parameter like current-pict-alignment-mode
values 'old-and-broken
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.
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.
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*
.
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:).
@mflatt Would you like me to open a PR, or would you rather just make the change yourself?
I’ll submit a PR to make sure we have the same changes in mind.
Alright, that sounds good.
@jbclements You latest commit for portaudio broke it for linux
callbacks.so
does not exist.
Oh! Thank you, I’ll try this tonight.
It works! I wish they accepted the pull request.
The PR still needs some polishing, but it’s close to mergable
It looked like it was pretty close. I saw the last action taken on it was halfway through January.
Well, I wouldn’t know how close it was. Just that there was a decent amount of back-and-forth.