<mingy>
hello,I have a question about macro-stepper,I see "When your program consists of multiple top-level definitions or expressions, the macro stepper also provides “Previous term” and “Next term” buttons to go up and down in the terms of your program.
<und-l-t-d[m]>
If I run `raco test` in the root of my project, it exits doing nothing (and without any error); regardless if I have `test-include-paths` defined in info.rkt
<und-l-t-d[m]>
Is it normal or have I misconfigured something? Also if I run `raco test .` it will test all the files even if I list only specific ones in `test-include-paths`
<und-l-t-d[m]>
That makes me wonder how `test-include-paths` are supposed to be used in practice
miskatonic has quit [Remote host closed the connection]
TCZ has joined #racket
TCZ has quit [Quit: Leaving]
TCZ has joined #racket
dddddd has joined #racket
badkins has joined #racket
badkins has quit [Ping timeout: 260 seconds]
badkins has joined #racket
TCZ has quit [Quit: Leaving]
bitmapper has joined #racket
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
TCZ has joined #racket
sagax has quit [Excess Flood]
notzmv has quit [Ping timeout: 258 seconds]
endformationage has joined #racket
TCZ has quit [Quit: Leaving]
badkins has quit [Remote host closed the connection]
badkins has joined #racket
badkins has quit [Ping timeout: 258 seconds]
pilne has joined #racket
badkins has joined #racket
Fare has joined #racket
nullcone has joined #racket
<jcowan>
How do you tell racket-the-CLI-repl what language you are using?
ArthurStrong has joined #racket
pilne has quit [Quit: Relax, its only ONES and ZEROS!]
<samth>
the `-I` flag
<samth>
although that does not set the lexical syntax
<dzoe>
samth: thanks for the help today
<dzoe>
I've been running all the tests for last 4 hours without a glitch
<samth>
dzoe: matthew did all the work :)
<jcowan>
samth: Thanks. It can't be changed dynamically then, like ,language in Guile?
<dzoe>
I am curious if I can pin-point the other dead-lock issue though :)
<samth>
if you have a reproduction for the other bug, even a big one, then we can probably fix t
<dzoe>
Well...
<samth>
jcowan: for languages that are just providing bindings, you can just require them
<dzoe>
Right now you have to run the whole graphics pipeline code for a long time on 2560x1440 screen ...
<dzoe>
And it is full of other ugly hacks, so the plan is to switch to safe code and start removing various parts.
<dzoe>
The bad thing is that I/O is useless for debugging here as it forces everything back into the runtime thread.
<dzoe>
I am also still investigating, why the 32bit memory references cannot be JIT inlined and 16bit can. Debugging racket is just a side-effect here :)
<dzoe>
That's why I say "They say Racket is slow" ... I can attest it isn't.
izh_ has joined #racket
pilne has joined #racket
<und-l-t-d[m]>
Anyone editing scribble files in Emacs? Which mode do you use?
<dzoe>
Probably terribly outdated in my installation.
<und-l-t-d[m]>
dzoe: Okay, I should then try that one. Pity it's not on melpa.
SGASAU has joined #racket
tlcu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samth>
dzoe: are 64-bit ones inlined?
badkins has joined #racket
<dzoe>
samth: nope, if I read the source correctly, only bytes-ref/u8vector-ref and u16vector-ref (and set!) are.
<dzoe>
The rest is just ptr-ref, which is inherently "slow".
<dzoe>
(it actually interpretes its arguments at runtime)
<samth>
dzoe: I hope you already know about the disassembler pkg, btw
<dzoe>
Yes, but so far it was enough to write a lots of benchmarks and read the source (which actually became quite readable after some time).
<dzoe>
I don't think I'm going to beat GPU shaders with Racket on CPU, but it is an interesting exploration.
<dzoe>
(Apparently yielding some useful results)
<dzoe>
There is still lot to do - Racket CS, ARM builds...
<dzoe>
Basically the whole thing does not make much sense under a windowing environment, but I am really curious about the performance on RPi with plain mmap-ed framebuffer.
<dzoe>
Also the CS part will probably be about documentation a lot.
<dzoe>
Apparently not every cpointer can be used as bytes under CS.
<dzoe>
Yet under 3m it is supposed to be.
SGASAU has quit [Ping timeout: 260 seconds]
notzmv has joined #racket
<samth>
the racketcs code for unsafe-bytes-ref looks like a big improvement over the racketbc code
<dzoe>
That definitely looks like different underlying structure.
<dzoe>
In 3m (almost) everything is Scheme_Object*
<dzoe>
That's why those dereferences.
<dzoe>
I'll look into that.
<dzoe>
Right now I am running 7.6 from PPA, master with latest GC patch and official 7.6 CS binary.
<samth>
the bytes representation is substantially different from racket bc
<samth>
(which is why there's the FFI difference around bytes)
<dzoe>
I am wondering whether it would finally be feasible to use uint32 for ARGB pixels efficiently.
<dzoe>
With BC the fastest image data representation is native word - which means using 64 bits per pixel on x86_64.
<dzoe>
Where is the source for the CS versions?
<dzoe>
racket/src/cs is very ... sparse I'd say?
<samth>
dzoe: the source for chez scheme (our version) is at github.com/racket/ChezScheme
<samth>
the IO system, thread system, and expander are all written in Racket for Racket CS, they're in racket/src/{io,expander,thread}
<samth>
the readme in racket/src/cs should be a good guide
<samth>
also, adding unsafe versions of the other u*vector ops should be really easy on Racket CS
<dzoe>
The last paragraph scares me: Using a macro to force inlining can be ok, but that technique should be used sparingly ...
<dzoe>
That is one of the techniques I use a lot in this project :)
<samth>
dzoe: it should be used sparingly only for the obvious reason -- inlining everything is often not an optimization
<dzoe>
Yes, yes, I agree. It's just that for example generating 4 procedures for texturing triangle each one with different pixel manipulation really benefits from explicit inlining.
<dzoe>
The actual algorithm can be kept readable and using syntax macros I just put the pixel manipulation at the right place.
<dzoe>
Passing procedures as arguments isn't optimized in this case at all.
<samth>
yes, i agree.
<dzoe>
But other Scheme-ish techniques work really well here - like clever usage of define versus let to limit the scope and allow the compiler to optimize out useless stuff is a great helper.
<dzoe>
I am kind of pondering the possibility of compiling the Racket code for GPU - that would be a VERY interesting research.
<dzoe>
Wow, gotta read that when I have more time.
<dzoe>
But to be honest, as I am pretty confident with racket/racket source right now, I am really lost in racket/ChezScheme, I need to dig through that first.
<dzoe>
Also, is there a plan to support ARM builds with CS?
<samth>
dzoe: you mean, to distribute binaries for ARM? it should already work if you build it yourself
<dzoe>
samth: OK, will try that as well
Fare has quit [Remote host closed the connection]
badkins has quit [Remote host closed the connection]
izh_ has quit [Quit: Leaving]
<dzoe>
Well, under CS, ptr-set! _uint8 is 4x faster than _uint16, this will be fun to investigate.
sauvin has quit [Ping timeout: 258 seconds]
aidalgol has quit [Remote host closed the connection]
aidalgol has joined #racket
sauvin has joined #racket
TCZ has joined #racket
SGASAU has joined #racket
sagax has joined #racket
efm has quit [Ping timeout: 256 seconds]
selimcan has joined #racket
benaiah has joined #racket
SGASAU has quit [Remote host closed the connection]
SGASAU has joined #racket
SGASAU has quit [Remote host closed the connection]
efm has joined #racket
rgherdt has quit [Quit: Leaving]
selimcan has quit [Quit: Leaving]
rgherdt has joined #racket
rgherdt has quit [Remote host closed the connection]
rgherdt has joined #racket
badkins has joined #racket
Fare has joined #racket
TCZ has quit [Quit: Leaving]
true-grue has quit [Read error: Connection reset by peer]
bremner has joined #racket
rgherdt has quit [Remote host closed the connection]