ok
One confounding factor here is that DrRacket sets the pretty-print-columns parameter when printing in the repl but doesn’t when you call print
I think that is what explains the newline and I think that my explanation about current-print vs print is the correct explanation.
And to be clear, I am not claiming that have a reason why racket mode is wrong. I am merely pointing out that drracket and racket mode set different parameters
So when we see differences it is because they do different things. I thought that sorting that out was the goal of this discussion.
(and to claify here, when I wrote “when printing in the REPL”, I mean that DrRacket doesn’t use read-eval-print-loop directly but the code that it uses instead of read-eval-print-loop is what is setting the column width for pretty printing; it does other things but for the purpose of this discussion, I think it is fine to say that that code counts as read-eval-print-loop and so is a separate part of the discussion.)
I was fine in theory but when I double-checked actual examples, it made me unsure and I wanted to ask again.
sounds good!
Also I remembered I actually had a bug where someone expected to be able to set port-write-handler in their program, and expected it to be restored on the next run: https://github.com/greghendershott/racket-mode/issues/381
My attempt to fix that caused another bug, linked from there.
And I fixed that.
Reading that, I would have assumed that this reasoning “Each racket-run gets a fresh custodian including a fresh dedicated thread for the REPL. As a result, parameters are reset. Therefore you expect port-write-handler to be reset. But it is not.” is correct (and that’s why drr does reset it, I would say)
So I’m a little cautious now. It seems users expect to be able to set this (at least port-write-handler) in their own programs. How am I supposed to handle that? At least with current-print I can say, “well the docs say that is for use by read-eval-print-loop, and Racket Mode ‘owns’ that, so tough beans.”. How can I say that about port-print-handler? Ugh.
I don’t understand
Here’s how I see from the drr perspective:
You create the initial thread that is going to run the program.
Before teh program is actually started, however, you set various parameters that create an initial environment for the program.
(Eg memory limits, printing thingies, etc etc etc)
Then you run the program.
If they run the program again, you do this process again
If they submit something to the repl you don’t do this process again.
I’m with you so far and that’s my understanding, too.
If a progrm sets any of the handlers then the initial setting that emacs mode (or drr) set is clobbered. tough beans in that case.
I’m not seeing how this perspective doesn’t work out!
(eom)
Normally I think about two entities here: The user and the tool. Some things are understood to be initially set by one, and changeable by the other. Great But I thought you were saying, a couple days ago: “Greg! Wait! There is a 3rd entity. The language”. And now I’m just confused how to mediate these parameters and settings among all 3, especially when hardly any are really documented wrt that.
(I thought you’d said, well current-print is something a lang might want to set, and that’s why Racket Mode shouldn’t use it.)
“The language” is part of the “program” code for the purpose of this discussion (assuming we’re talking about #lang-based languages, which is, IMO, all that racket mode should support and all that I wish DrRacket had to support)
What I mean to convey with what I said is that I cannot reconstruct the precise reason from my memory of history why we don’t set current-print but instead set the port print handler, and instead what I did was point out how they are different.
ymmv :slightly_smiling_face:
I don’t mean to “flog” or prolong this. I keep thinking “OK now I understand”, but start to go do something about it, and realize I feel uncertain after all, and worried about making a change that will cause or regress some other issue. :disappointed: Also I guess a lot of my brain bandwidth is still consumed with everything I’ve changed recently to support check-syntax. You might be seeing some brain contents sloshing over the edge of the bucket.
I’m totally fine with prolonging this as long as you are! As a general point, I am very happy that we are in discussion about how to keep the two main racket IDEs in sync (or not, as appropriate). I’m also happy to have this discussion on your schedule. I’m also delighted that you’re using the (overly complicated…..) check syntax api! Let’s revisit this at some later point.
AS far as regression that was a big worry for me until I spent a bunch of time building a “auto click on drracket’s gui” test suite that had a bunch of twisty “I run this annoying program, lets see how you break now, drracket” -type test cases
Having that is a big relief!
I know that’s going to sound like adding something to your plate, not removing it.
:disappointed:
Sorry
I do have some UI level smoke tests — e.g. “open a REPL, type some things, type TAB, does it complete….” — but the surface area of Racket Mode is pretty huge by now so the coverage % is low. Also I have a lot of tests for indent and font-lock (syntax highlighting) including regression tests as things get fixed. But yes there’s always a lot more to do. I think wrt things like printing I would need to add more tests where user program text is expanded and/or evaluated, i.e. even more .rkt files to use in testing beyond the couple I already use for indent/font-lock testing.
yeah
The test cases in this file were a real turning point for me in being able to tell what exactly was going to break when I changed the initial handlers set up for the repl. It probably isn’t a good set if I were starting over, tho, as the code is very old and has test cases that are effectively redundant now (when I wrote them I knew a lot less about how things were going to play out than I know today) but I’m not going to delete any :slightly_smiling_face:
How do I fix this type error from Typed Racket? #lang typed/racket
(require math/matrix math/array)
(: pivot-indices : (Matrix Real) -> (Vectorof Index))
; return a vector v such that M_i,v_i is the pivot of row i
(define (pivot-indices M)
(define n (square-matrix-size M))
; Get a vector of vectors representation of M.
; Now (vector-ref vs i) is the i'th row of M.
(define vs (array->vector* M))
(find-row-pivot : Index -> Index)
(define (find-row-pivot i)
(define v (vector-ref vs i))
(let loop ([j 0] [jmax 0] [max 0])
(cond
[(= j n) jmax]
[else (define x (abs (vector-ref v j)))
(if (> x max)
(loop (+ j 1) j x)
(loop (+ j 1) jmax max))])))
(build-vector n find-row-pivot))
The error is: ; /Users/soegaard/tmp/pivot.rkt:17:26: Type Checker: type mismatch
; expected: VectorTop
; given: (Rec x₀ (U (Vectorof x₀) Real))
; in: vs
; [Due to errors, REPL is just module language, requires, and stub definitions]
The offending expression is (vector-ref vs i).
If I use array->vector* on an example, I get: > (array->vector* G)
- : (Rec x₀ (U (Vectorof x₀) Real))
'#(#(1 0 0 0)
#(0 4.632679487995776e-05 0.999999998926914 0)
#(0 -0.999999998926914 4.632679487995776e-05 0)
#(0 0 0 1))
(Rec x₀ (U (Vectorof x₀) Real)) is not a vector .
How do I turn it into one?
For a matrix array->vector* will always return a vector of vector.
Can you point me to the repo?
Oh! I just found matrix->vector* …
Still in the case of an matrix, the result ought to be a vector of vectors.
I was expecting matrix->vector* to reuse array->vector*, but no… (matrix->vector* : (All (A) (Matrix A) -> (Vectorof (Vectorof A))))
(define (matrix->vector* a)
(cond [(matrix? a) (parameterize ([array-strictness #f])
(array->vector ((inst array-axis-reduce A (Vectorof A)) a 1 build-vector)))]
[else (raise-argument-error 'matrix->vector* "matrix?" a)]))
I think the type definition is not right.
What’s wrong?
It says (Vectorof* A) could be a A or a recursively defined (Vectorof A)
I think that’s due to arrays with more than 2 axes.
If you plug in Number for A, it means 10 is also a (Vectorof* Number) which is not desirable to my understanding.
You have a point.
I might try (Rec T (U (Vectorof A) (Vectorof T))
see if this works
Just noticed that extracted Racket CS has the size of 1GB!
Yikes! Hopefully this will help: https://github.com/cisco/ChezScheme/pull/500
Dybvig says that Petite Chez Scheme’s size actually increases with that PR, so I really don’t know if the PR will actually help RacketCS
Oh…
At least we will get faster load times.
One thing I notice is that a lot of the compiled Scheme file has two " characters every line. Can we elide them somehow? Not sure if that will help though
Note that Racket CS uses a different code format called vfasl (which is not in upstream Chez)
I did not know that.
Also, just want to report another win for Racket CS. I have a program that builds a tree based on a trace of events. I implemented it in two different ways. One with explicit parent pointer, and another with parameterize:
$ for i in {1..10}; do /Applications/Racket\ v7.6\ CS/bin/racket parent.rkt; done
cpu time: 1631 real time: 1695 gc time: 1178
cpu time: 1589 real time: 1631 gc time: 1140
cpu time: 1644 real time: 1720 gc time: 1182
cpu time: 1579 real time: 1621 gc time: 1120
cpu time: 1574 real time: 1608 gc time: 1132
cpu time: 1560 real time: 1605 gc time: 1125
cpu time: 1555 real time: 1585 gc time: 1114
cpu time: 1556 real time: 1585 gc time: 1110
cpu time: 1578 real time: 1621 gc time: 1121
cpu time: 1592 real time: 1634 gc time: 1131
$ for i in {1..10}; do /Applications/Racket\ v7.6\ CS/bin/racket param.rkt; done
cpu time: 3589 real time: 3730 gc time: 1582
cpu time: 3679 real time: 3896 gc time: 1632
cpu time: 3571 real time: 3733 gc time: 1587
cpu time: 3476 real time: 3573 gc time: 1546
cpu time: 3433 real time: 3525 gc time: 1540
cpu time: 3526 real time: 3645 gc time: 1548
cpu time: 3495 real time: 3609 gc time: 1555
cpu time: 3568 real time: 3672 gc time: 1584
cpu time: 3437 real time: 3529 gc time: 1541
cpu time: 3492 real time: 3580 gc time: 1541
$ for i in {1..10}; do racket parent.rkt; done
cpu time: 1979 real time: 2059 gc time: 1613
cpu time: 1976 real time: 2039 gc time: 1606
cpu time: 1999 real time: 2170 gc time: 1625
cpu time: 1976 real time: 2010 gc time: 1611
cpu time: 2050 real time: 2184 gc time: 1675
cpu time: 1992 real time: 2071 gc time: 1625
cpu time: 2094 real time: 2316 gc time: 1701
cpu time: 2141 real time: 2681 gc time: 1741
cpu time: 2062 real time: 2261 gc time: 1681
cpu time: 2054 real time: 2169 gc time: 1670
$ for i in {1..10}; do racket param.rkt; done
cpu time: 4376 real time: 4514 gc time: 2146
cpu time: 4341 real time: 4449 gc time: 2122
cpu time: 4331 real time: 4416 gc time: 2111
cpu time: 4333 real time: 4421 gc time: 2116
cpu time: 4488 real time: 4650 gc time: 2129
cpu time: 4575 real time: 4951 gc time: 2197
cpu time: 4856 real time: 5889 gc time: 2347
cpu time: 4577 real time: 4807 gc time: 2238
cpu time: 4475 real time: 4747 gc time: 2175
cpu time: 4880 real time: 5375 gc time: 2445
This would help with using the HTTP client from net with an alternate transport layer, except that it’s broken: https://github.com/racket/compatibility/issues/8
@danilomendoncaoliveir has joined the channel
Reusing the HTTP client from net is a totally reasonable thing to want, but just for the record that client is pretty terrible