[racket-users] Making a text editor

[Kevin Forchione]

Hi guys,
I’ve been perusing the documentation on Racket GUI and am interested in making 
a text editor. Is there any source code to model from? The documentation got me 
started, but there are features such as indenting, line numbering and 
keybindings that I’m interested in implementing. I’ve done a bit of searching 
online and see that we’ve got examples using the 2htdp packets and a VI 
graphical editor, but nothing that quite fits the bill for what I’m doing. 

Any pointers are appreciated!

-Kevin

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Making a text editor

[Vincent St-Amour]

Have you looked at rmacs?

https://github.com/tonyg/rmacs

Vincent



On Sun, 31 Jan 2016 13:42:23 -0600,
Kevin Forchione wrote:
> 
> Hi guys,
> I’ve been perusing the documentation on Racket GUI and am interested in 
> making a text editor. Is there any source code to model from? The 
> documentation got me started, but there are features such as indenting, line 
> numbering and keybindings that I’m interested in implementing. I’ve done a 
> bit of searching online and see that we’ve got examples using the 2htdp 
> packets and a VI graphical editor, but nothing that quite fits the bill for 
> what I’m doing. 
> 
> Any pointers are appreciated!
> 
> -Kevin
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] link: bad variable linkage

[Robby Findler]

Then it would be helpful to us if you could provide some (hopefully
small) program and instructions to reproduce the problem.

Thanks,
Robby


On Sun, Jan 31, 2016 at 4:51 PM, jon stenerson  wrote:
> Just using DrRacket 6.3 on Win 10.
>
> Jon
>
>
> On 1/31/2016 3:22 PM, Robby Findler wrote:
>>
>> The compilation of racket is (not yet) deterministic so things like
>> that can throw off internal tables in the .zo files (and a .zo files
>> is loaded without checking dependencies, optimistically hoping that
>> the files are not changed).
>>
>> So: are you using "raco make" or somehow mangaging .zo files yourself,
>> or are you seeing this with the .zo files that DrRacket maintains for
>> your automatically? If the former, then you need to adapt your
>> workflow to either not use .zo files or to keep them up to date. If
>> the latter, then it is a bug.
>>
>> Robby
>>
>>
>>
>> On Sun, Jan 31, 2016 at 4:17 PM, jon stenerson 
>> wrote:
>>>
>>> I have some .rkt files and, depending on which file was edited most
>>> recently, either it works fine or it gives a compilation error. (By
>>> "edited"
>>> I mean just adding or subtracting a blank line to change the timestamp).
>>> I
>>> can submit a simplified example if nobody else has seen this problem.  If
>>> this is well-known, what is the fix?
>>>
>>> link: bad variable linkage;
>>>   reference to a variable that is not a procedure or structure-type
>>> constant
>>> across all instantiations
>>>reference phase level: 0
>>>variable module: 
>>>variable phase: 0
>>>reference in module:  in: 
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] link: bad variable linkage

[jon stenerson]

The simplest thing I can find: I have three files in two directories.
The first directory, called junk, contains a.rkt and b.rkt.
The second directory is a sibling to junk called local-libs and contains 
c.rkt. (local-libs is known to the package manager; it was installed via 
the DrRacket interface).
If I open all three files in DrRacket and try running a.rkt, sometimes 
it works, sometimes not. By modifiying a, b, c in some order (in the 
DrRacket editor) I can toggle the work/not work flag. As you say, it's a 
little non-deterministic.


Thanks,
Jon


a.rkt:
#lang racket
(require "b.rkt")

b.rkt
#lang racket
(require "../local-libs/c.rkt")
(s 1)

c.rkt
#lang racket
(provide (struct-out s) )
(struct s (p))



On 1/31/2016 4:03 PM, Robby Findler wrote:

Then it would be helpful to us if you could provide some (hopefully
small) program and instructions to reproduce the problem.

Thanks,
Robby


On Sun, Jan 31, 2016 at 4:51 PM, jon stenerson  wrote:

Just using DrRacket 6.3 on Win 10.

Jon


On 1/31/2016 3:22 PM, Robby Findler wrote:

The compilation of racket is (not yet) deterministic so things like
that can throw off internal tables in the .zo files (and a .zo files
is loaded without checking dependencies, optimistically hoping that
the files are not changed).

So: are you using "raco make" or somehow mangaging .zo files yourself,
or are you seeing this with the .zo files that DrRacket maintains for
your automatically? If the former, then you need to adapt your
workflow to either not use .zo files or to keep them up to date. If
the latter, then it is a bug.

Robby



On Sun, Jan 31, 2016 at 4:17 PM, jon stenerson 
wrote:

I have some .rkt files and, depending on which file was edited most
recently, either it works fine or it gives a compilation error. (By
"edited"
I mean just adding or subtracting a blank line to change the timestamp).
I
can submit a simplified example if nobody else has seen this problem.  If
this is well-known, what is the fix?

link: bad variable linkage;
   reference to a variable that is not a procedure or structure-type
constant
across all instantiations
reference phase level: 0
variable module: 
variable phase: 0
reference in module:  in: 

--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] link: bad variable linkage

[jon stenerson]

I have some .rkt files and, depending on which file was edited most 
recently, either it works fine or it gives a compilation error. (By 
"edited" I mean just adding or subtracting a blank line to change the 
timestamp). I can submit a simplified example if nobody else has seen 
this problem.  If this is well-known, what is the fix?


link: bad variable linkage;
 reference to a variable that is not a procedure or structure-type 
constant across all instantiations

  reference phase level: 0
  variable module: 
  variable phase: 0
  reference in module:  in: 

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] link: bad variable linkage

[jon stenerson]

Just using DrRacket 6.3 on Win 10.

Jon

On 1/31/2016 3:22 PM, Robby Findler wrote:

The compilation of racket is (not yet) deterministic so things like
that can throw off internal tables in the .zo files (and a .zo files
is loaded without checking dependencies, optimistically hoping that
the files are not changed).

So: are you using "raco make" or somehow mangaging .zo files yourself,
or are you seeing this with the .zo files that DrRacket maintains for
your automatically? If the former, then you need to adapt your
workflow to either not use .zo files or to keep them up to date. If
the latter, then it is a bug.

Robby



On Sun, Jan 31, 2016 at 4:17 PM, jon stenerson  wrote:

I have some .rkt files and, depending on which file was edited most
recently, either it works fine or it gives a compilation error. (By "edited"
I mean just adding or subtracting a blank line to change the timestamp). I
can submit a simplified example if nobody else has seen this problem.  If
this is well-known, what is the fix?

link: bad variable linkage;
  reference to a variable that is not a procedure or structure-type constant
across all instantiations
   reference phase level: 0
   variable module: 
   variable phase: 0
   reference in module:  in: 

--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Making a text editor

[Jens Axel Søgaard]

Perhaps you can get some ideas here?

https://github.com/soegaard/bracket/blob/master/gui/racket-cas.rkt#L411

It's not the best example, but I don't know of a "Notepad" application
written in Racket.

/Jens Axel


2016-01-31 20:42 GMT+01:00 Kevin Forchione :

> Hi guys,
> I’ve been perusing the documentation on Racket GUI and am interested in
> making a text editor. Is there any source code to model from? The
> documentation got me started, but there are features such as indenting,
> line numbering and keybindings that I’m interested in implementing. I’ve
> done a bit of searching online and see that we’ve got examples using the
> 2htdp packets and a VI graphical editor, but nothing that quite fits the
> bill for what I’m doing.
>
> Any pointers are appreciated!
>
> -Kevin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
Jens Axel Søgaard

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Looking for suggestion on accumulating the paths of Graph from HtDP

[Matthias Felleisen]

I think you may wish to read How to Design Programs. Here are something that 
are missing: 

— data definitions (what’s a graph? what’s a path) 
— signatures 
— examples
— tests 

Once you supply those missing pieces, you will make much more progress. If you 
post those, we can also help you make real progress, not just complete a 
problem from HtDP/2e. 


> On Jan 30, 2016, at 11:29 PM, liweijian  wrote:
> 
> HtDP taught us how to check if there exists path(s) from one node to another.
> 
> I tried to implement accumulating all the paths between two nodes as:
> 
> ```racket
> (define (find-paths origin dest G path)
>  (cond
>[(equal? origin dest) (reverse (cons dest path))]
>[else
> (find-paths/all (neighbors origin G) dest G (cons origin path))]))
> 
> (define (find-paths/all lons dest G path)
>  (cond
>[(empty? lons) '(#f)]
>[else
> (map (λ (n) (find-paths n dest G path)) lons)]))
> ```
> 
> However, when I tested it by
> 
> ```racket
> (define sample-graph
>  '((A (B E))
>(B (E
> 
> (define (neighbors origination G)
>  (cadr (assoc origination G)))
> 
> (find-paths 'A 'E sample-graph '())
> ```
> 
> The answer is: '(((A B E)) (A E))
> 
> In order to get the right answer, I have to write another `flatten` function 
> as:
> 
> ```racket
> (define (flatten-path lop)
>  (cond
>[(empty? lop) empty]
>[(not (list? (caar lop))) (cons (first lop) (flatten-path (rest lop)))]
>[else
> (append (flatten-path (first lop)) (flatten-path (rest lop)))]))
> 
> (filter (λ (path) (not (boolean? (car path (flatten-path (find-paths 'A 
> 'E sample-graph '(
> ```
> 
> And now it works.
> 
> I was wondering if maybe I could improve it? 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: appending files

[Scotty C]

On Sunday, January 31, 2016 at 12:13:31 AM UTC-6, Scotty C wrote:
> > that's what i did. so new performance data. this is with bytes instead of 
> > strings for data on the hard drive but bignums in the hash still.
> > 
> > as a single large file and a hash with 203 buckets for 26.6 million 
> > records the data rate is 98408/sec.
> > 
> > when i split and go with 11 smaller files and hash with 59 buckets the 
> > data rate is 106281/sec.
> 
> hash is reworked, bytes based. same format though, vector of bytes. so time 
> test results:
> 
> single large file same # buckets as above data rate 175962/sec.
> 
> 11 smaller files same # buckets as above data rate 205971/sec.

throughput update. i had to hand code some of the stuff (places are just not 
working for me) but i just managed to hack my way through running this in 
parallel. i copied the original 26.6 million records to a new file. ran two 
slightly reworked copies of my duplicate removal code at a shell prompt like 
this:
racket ddd-parallel.rkt &
racket ddd-parallel1.rkt &
i'm not messing with the single large file anymore. so for twice the data the 
data rate is up to 356649/sec.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Standardizing the threading macro and organizing packages

[Alexis King]

> On Jan 29, 2016, at 21:55, Brian Adkins  wrote:
> 
> Was any consensus reached on this? I've been working through some exercises 
> in Racket that a friend is implementing in Elixir, and I just came across a 
> "method chaining" situation. I ended up simply writing a wrapper function, 
> but using a version of ~> would've been nice.

Yes, actually, there was. The “threading” package was the result, and
you can find the documentation here[1]. I believe rackjure’s threading
implementation now also uses this package, so at least some level of
standardization has been reached.

If you want Clojure-style threading macros, the threading package is
probably your best bet. Of course, that might not actually be what you
want: consider also looking at the different ~> from the point-free
package, which is actually a higher-order function. When paired with a
shorthand function package (which didn’t ever get standardized), it can
be a little more powerful (and just as concise) than a dumb macro.

> On Jan 31, 2016, at 05:58, Greg Trzeciak  wrote:
> 
> With Refinements being currently added 
> (http://andmkent.com/blog/2015/07/06/stop-2015-talk-adding-practical-dependent-types-to-typed-racket/):
> 1. Is the argument of using ~> no longer valid since refinements also use it.
> 2. Is adding refinements going to cause some conflicts with the existing 
> threading implementations?

I would say no. I’m not sure if the refinement syntax is set in stone,
and even if it is, the name of this particular macro has a relatively
long history in the Racket world, so it doesn’t make much sense to
change it now. In the event that the two are used together and do,
indeed, collide, then Racket’s ample namespace management tools are easy
enough to use to resolve the conflict.

[1]: http://pkg-build.racket-lang.org/doc/threading/index.html

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Using local-expand to mostly expand a module?

[Matthew Flatt]

I think you need to use a trampoline for the module body's expansion,
where you expand only one module-body form at a time and let
`#%module-begin` finish up forms like `require` or `define-syntaxes`
before you macro continues with later forms.

The general pattern is that you have a macro `do-module-begin` where

 (do-module-begin
  expr-0
  expr ...)

turns into 

 (begin
  expanded-expr-0
  (do-module-begin
   expr ...))

where `expr-0` is `local-expand`ed and transformed as needed. The base
module-body expander will process `expanded-expr-0`, importing and
binding macros as needed, before continuing with `(do-module-begin expr
...)` for the rest of the module.

For an example, see the implementation of `syntax/wrap-modbeg`.

This pattern shows up frequently, but I've never hit on quite the right
abstraction to turn the pattern into a library. It's probably just a
matter of trying harder.

At Fri, 29 Jan 2016 21:29:16 -0800 (PST), reilithion wrote:
> I'm trying to make a little EDSL that has one form that is special and needs 
> to be collected and later processed. I want to allow a user of the EDSL to 
> write a macro that expands to the special form. I have a module-begin that 
> (so 
> far) looks like this:
> 
> (define-syntax (module-begin stx)
>   (syntax-parse stx
> ((_ module-contents ...)
>  (let-values
>   ([(tasks other)
> (partition
>  (syntax-parser #:literals (task-internal) ((task-internal _ ...) #t) 
> (_ #f))
>  (rest
>   ;; Problems start here
>   (syntax->list
>(local-expand
> #'(#%plain-module-begin module-contents ...)
> 'module-begin
> (list #'task-internal #'module* #'#%app)])
>   #`(#%module-begin
>  #,@other
>  (define all-tasks (list #,@tasks))
>  (process all-tasks))
> 
> If I don't bother with the local-expand and just use (rest (syntax->list 
> stx)), it works basically fine but won't treat macros that expand to 
> task-internal specially. I tried mapping local-expand over (syntax->list 
> stx), 
> but that led to strange errors when I tried to define macros within the EDSL.
> 
> This current implementation fails because it expands too much too soon. A 
> macro will happily expand into (task-internal args ...), then (task-internal1 
> args ...), then (#%app task-internal1 args ...), and then the call to 
> partition won't see what it's expecting (in fact, I think it CAN'T see what 
> it 
> needs to, because I suspect the local-expand of the #%plain-module-begin 
> effectively hides the task-internal identifier).
> 
> I added a bunch of stuff to the stop-ids list, hoping it would bail before 
> transforming task-internal beyond recognition, but nothing I added seemed to 
> work.
> 
> I also tried calling local-expand on #'(begin module-contexts ...) with the 
> 'top-level context-v, but of course begin is automatically added to the 
> stop-ids list and local-expand stops right away.
> 
> Can I somehow get local-expand to only mostly expand a module? How do I do 
> what I'm trying to do here?
> 
> Thanks!
> Lucas Paul
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Standardizing the threading macro and organizing packages

[Greg Trzeciak]

On Thursday, October 8, 2015 at 5:09:20 AM UTC+2, Alexis King wrote:
> While in St. Louis, I had a brief conversation with Jay, Alex, and Jack about 
> how we all happen to have our own implementation of Clojure’s threading 
> macro. That macro is called -> in Clojure, but I believe Greg’s rackjure 
> library set the Racket standard of calling it ~>, since the arrow is already 
> used by contracts and types (and the FFI, too, for that matter). I have no 
> idea how many implementations of this macro exist in the wild, but 5 is 
> already far too many.

With Refinements being currently added 
(http://andmkent.com/blog/2015/07/06/stop-2015-talk-adding-practical-dependent-types-to-typed-racket/):
1. Is the argument of using ~> no longer valid since refinements also use it.
2. Is adding refinements going to cause some conflicts with the existing 
threading implementations? 

Thanks
Greg

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.