[racket-users] Re: Unit test inner procedures

[Zelphir Kaltstahl]

Huh, that looks reasonable.
So far I've not used modules much, except the implicit one by:
~~~
#lang racket
~~~
So the example is helpful.
The tests are not in another file, but at least they are not inside a 
wrapping procedure and are in a way separate.
Maybe I should have a look at the different ways of defining modules again 
and use them more.

On Monday, November 27, 2017 at 10:15:38 PM UTC+1, Jack Firth wrote:
>
> I don't think you can directly test an inner procedure while keeping your 
> test code separately loadable (e.g. different file or module). It doesn't 
> seem like a good idea to me, personally. Inner procedures communicate to me 
> that I can change, reorganize, delete, and otherwise do whatever I want to 
> them without breaking any code outside the definition of the outer 
> procedure. Breaking tests in a different file with a refactoring of an 
> inner procedure would be *very *surprising to me.
>
> Instead, I recommend not using inner procedures so extensively. Instead 
> define functions within modules (or possibly submodules) and use `provide` 
> with `contract-out` to declare which functions make the public API of your 
> module. You can then add a test submodule which has access to the inner 
> workings of the outer module and test "private" helper functions that way. 
> Here's an example:
>
> #lang racket;; note that using #lang implicitly creates a module around 
> the whole file
>
> (provide
>   (contract-out
> [my-public-function (-> input? output?)]))
>
> (define (my-public-function input)
>   (helper2 (helper1 input)))
>
> (define (helper1 input) ...)
> (define (helper2 input) ...)
>
> (module+ test ;; inside this submodule we can see helper1 and helper2, 
> even though they're not provided
>   (require rackunit)
>   (check-equal? (helper1 test-input) test-output)
>   ... more tests here ...)
>

-- 
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] Re: Unit test inner procedures

['John Clements' via Racket Users]

+1. Totally agree.

> On Nov 27, 2017, at 1:15 PM, Jack Firth  wrote:
> 
> I don't think you can directly test an inner procedure while keeping your 
> test code separately loadable (e.g. different file or module). It doesn't 
> seem like a good idea to me, personally. Inner procedures communicate to me 
> that I can change, reorganize, delete, and otherwise do whatever I want to 
> them without breaking any code outside the definition of the outer procedure. 
> Breaking tests in a different file with a refactoring of an inner procedure 
> would be very surprising to me.
> 
> Instead, I recommend not using inner procedures so extensively. Instead 
> define functions within modules (or possibly submodules) and use `provide` 
> with `contract-out` to declare which functions make the public API of your 
> module. You can then add a test submodule which has access to the inner 
> workings of the outer module and test "private" helper functions that way. 
> Here's an example:
> 
> #lang racket;; note that using #lang implicitly creates a module around the 
> whole file
> 
> (provide
>   (contract-out
> [my-public-function (-> input? output?)]))
> 
> (define (my-public-function input)
>   (helper2 (helper1 input)))
> 
> (define (helper1 input) ...)
> (define (helper2 input) ...)
> 
> (module+ test ;; inside this submodule we can see helper1 and helper2, even 
> though they're not provided
>   (require rackunit)
>   (check-equal? (helper1 test-input) test-output)
>   ... more tests here ...)
> 
> -- 
> 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] Re: Alternatives to DrRacket

[George Neuner]

On 11/27/2017 3:30 PM, Zelphir Kaltstahl wrote:


Memory limits can be easily added to a program as well with the 
following code:


~~~
(define (Mb-to-B n) (* n 1024 1024))
(define MAX-BYTES (Mb-to-B 128))
(custodian-limit-memory (current-custodian) MAX-BYTES)
~~~


The problem with  custodian-limit-memory  is that it doesn't actually 
limit how much memory the custodian can allocate - the limit is enforced 
only *after* GC runs.  Between GC runs, the custodian could allocate far 
more than the limit.


I'd like a command line switch that puts a hard limit on heap size ... 
similar to the server JVM.  Using ULIMIT on Linux you can restrict 
process data size, but Windows offers no simple way to do that.  It can 
be done clumsily on Windows using containers or with "job objects", but 
few people have containers set up on their Windows boxes and the few job 
objects tools I am aware of work only on already running processes ... 
there's no simple way to start a process that is restricted from the 
beginning.


George

--
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: Unit test inner procedures

[Jack Firth]

I don't think you can directly test an inner procedure while keeping your 
test code separately loadable (e.g. different file or module). It doesn't 
seem like a good idea to me, personally. Inner procedures communicate to me 
that I can change, reorganize, delete, and otherwise do whatever I want to 
them without breaking any code outside the definition of the outer 
procedure. Breaking tests in a different file with a refactoring of an 
inner procedure would be *very *surprising to me.

Instead, I recommend not using inner procedures so extensively. Instead 
define functions within modules (or possibly submodules) and use `provide` 
with `contract-out` to declare which functions make the public API of your 
module. You can then add a test submodule which has access to the inner 
workings of the outer module and test "private" helper functions that way. 
Here's an example:

#lang racket;; note that using #lang implicitly creates a module around the 
whole file

(provide
  (contract-out
[my-public-function (-> input? output?)]))

(define (my-public-function input)
  (helper2 (helper1 input)))

(define (helper1 input) ...)
(define (helper2 input) ...)

(module+ test ;; inside this submodule we can see helper1 and helper2, even 
though they're not provided
  (require rackunit)
  (check-equal? (helper1 test-input) test-output)
  ... more tests here ...)

-- 
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] Unit test inner procedures

[Zelphir Kaltstahl]

Sometimes I find myself thinking: "I should really write some tests for all 
of this!"
But then I ask myself: "Uhm, how can I test some of the inner procedures of 
this procedure?"

I sometimes use inner procedures when no other part of the code needs 
access to some procedure and it fits purpose-wise into that wrapping 
procedure.
It is also helpful to wrap things, which I want to be exchangeable. For 
example for some xexpr rendering on a website, I could make a renderer for 
the whole website, which then internally is broken down into parts, which 
are all implemented by their own procedures, which are inner procedures to 
the all-wrapping renderer. This way I can return some procedure which uses 
these inner procedures (its in the closure's environment). This seems very 
useful to me and I would like to keep some code that way. It also keeps 
namespaces cleaner and makes naming easier, because a procedure inside a 
wrapping procedure can have simpler names than outside of it in some cases.

However I have this problem of "How to unit test these inner procedures?" 
Ideally I would not need to put tests into the wrapping procedure, but 
could keep the tests separate in another file.

Here is some code example:

~~~
(define (modulator clazz)
  (define (modulo a-number)
(remainder a-number clazz))
  modulo)
(let ([my-modulator (modulator 7)])
  (displayln "My modulator will do the job!")
  (my-modulator 50))
~~~

(OK this is a very artificial example.)
How would I unit test the `modulo` procedure, without taking it outside of 
its wrapping procedure? Is there an easy way this can be done? (or maybe 
inner procedure unit testing is a big no-no? If so, why?)

-- 
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: Alternatives to DrRacket

[Stephen De Gabrielle]

I don’t want to stop the responses, but I do want to say thank you to all
of you. You have given me a lot to think about.

Kind regards,

Stephen

-- 
Kind regards,
Stephen
--
Ealing (London), UK

-- 
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: Alternatives to DrRacket

[Zelphir Kaltstahl]

I mostly like the text navigation features I have in Emacs. I also like 
that I can run a shell inside Emacs and manage multiple buffers easily. 
Installing different color themes is easy too, while in DrRacket I would 
probably have to configure the colors myself (I might be wrong though, not 
sure if there isn't an easy way to get many themes into DrRacket).

I've never used DrRacket for a long time. Even the fancy arrows where 
something comes from when you hover it with the mouse cursor did not do 
much for me, because I either already knew where it came from, because I 
wrote the code myself, or because the arrow would come from something out 
of visible area. This also happens when you have an error and it tries to 
help you with the arrows. If it was somehow more usable (I have no idea 
how), maybe it would do something for me too.
What I used DrRacket for once were the examples for multi-threading and 
multi-processing in the Racket guide. It has nice visualization for this 
stuff, which I cannot get easily from Emacs.

When I need more of a backtrace, I simply run my programs with: `racket -l 
errortrace -t myfile.rkt` (that is a lowercase L, not an uppercase i)
Memory limits can be easily added to a program as well with the following 
code:

~~~
(define (Mb-to-B n) (* n 1024 1024))
(define MAX-BYTES (Mb-to-B 128))
(custodian-limit-memory (current-custodian) MAX-BYTES)
~~~

So I am usually not missing anything DrRacket would give me. Maybe if I was 
using more languages or more of the debugging tooling it offers I would use 
DrRacket more often.
One thing I liked was the integrated package manager. But that too can be 
handled easily with the `raco`.

-- 
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: Alternatives to DrRacket

[ben.rudgers]

I use Emacs because org-mode provides Babel and Babel lets me program in a 
literate style.  In Emacs I can write literate code irrespective of 
language and I enjoy literate programming more than 
illiterate/unlitterate/conventional programming by a wide margin. Emacs 
org-mode lets me convert my literate program to web pages, markdown, and 
other things I don't use. So it fills in for Scribble (I found Scribble-LP 
challenging to use, probably in part because it does not have the same size 
of community). 

So I'd love to see org-mode Babel in DrRacket...or DrRacket in Emacs.

Ben

-- 
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] Alternatives to DrRacket

[Sam Caldwell]

documentation (albeit limited) on the macro stepper:
http://docs.racket-lang.org/macro-debugger/index.html#%28part._.Using_the_.Macro_.Stepper%29

You can also find `expand/step` there, which I find to be a very useful
complement to using DrRacket to step through the expansion of an entire
module.

- Sam Caldwell

On Mon, Nov 27, 2017 at 11:33 AM, Damien MATTEI 
wrote:

> Le Monday 27 November 2017 05:18:02 pm David Storrs, vous avez écrit :
>
> >
> > > 2. The macro stepper is extremely handy when it works, and being able
> to
> > > inspect syntax objects in the interactions pane is wonderful when the
> > > macro stepper doesn't work.
> >
> > Offtopic:  This is the one big feature that I've tried DrRacket for,
> > but I've never been able to make it work. Everything gets reduced to
> > lambdas instead of more high-level forms so that long before I
> > actually see anything useful I get a giant mess.   Maybe I don't
> > understand it well enough, or maybe there's something I need to do
> > differently with it?  I was expecting to just keep clicking the 'step'
> > button; is there any sort of context or etc that I need to establish
> > first?
> >
>
> not easy to use, i never succeed to use it too , any documentation
> somewhere about the macro-stepper use?
>
> --
> 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] Examples of in-source documentation?

[David Storrs]

On Sun, Nov 26, 2017 at 12:10 AM, Greg Hendershott
 wrote:
> As another example of using scribble/srcdoc, for Frog I made a
> `define-doc` macro:
>
>   
> https://github.com/greghendershott/frog/blob/master/frog/private/define-doc.rkt
>
> Example usage:
>
>   https://github.com/greghendershott/frog/blob/master/frog/paths.rkt#L258-L268
>
> Where that gets pulled into the main frog.scrbl is the
> `include-extracted` last line here:
>
>   
> https://github.com/greghendershott/frog/blob/master/frog/frog.scrbl#L959-L975
>
> (In other words, there is still a main scribble file for "user guide"
> and module-wide documentation. Where scribble/srcdoc helps is with
> per-definition "reference" portions of the doc.)

Thanks, I appreciate the pointer.  Side benefit:  Frog looks really
useful and I may take a swing at using it.

Unfortunately, this is again something that mixes code and
documentation pretty incestuously and looks like code with some
strings sprinkled in.  The scribble file, of course, is very clear and
easy to follow but doesn't include the code and requires a specific
#lang.


This is probably just my issue and I should suck it up and get used to
the way that the new thing does it instead of expecting it to work
like the old thing.  Thanks for the feedback, everyone.

-- 
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] Examples of in-source documentation?

[David Storrs]

On Fri, Nov 24, 2017 at 9:13 PM, Neil Van Dyke  wrote:
> Does the following do something like you want?
>
> Subject: single-file packages and embedded documentation and metadata
> Date: Fri, 10 Nov 2017 23:04:39 -0500
> https://groups.google.com/forum/#!topic/racket-users/ulO8zxP46DI
>

Not really, I'm afraid.  This looks like code with strings mixed in
when I was hoping for strings with a dollop of code mixed in.  It
certainly does produce beautiful output, though.

-- 
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] Alternatives to DrRacket

[Damien MATTEI]

Le Monday 27 November 2017 05:18:02 pm David Storrs, vous avez écrit :

> 
> > 2. The macro stepper is extremely handy when it works, and being able to
> > inspect syntax objects in the interactions pane is wonderful when the
> > macro stepper doesn't work.
> 
> Offtopic:  This is the one big feature that I've tried DrRacket for,
> but I've never been able to make it work. Everything gets reduced to
> lambdas instead of more high-level forms so that long before I
> actually see anything useful I get a giant mess.   Maybe I don't
> understand it well enough, or maybe there's something I need to do
> differently with it?  I was expecting to just keep clicking the 'step'
> button; is there any sort of context or etc that I need to establish
> first?
> 

not easy to use, i never succeed to use it too , any documentation somewhere 
about the macro-stepper use?

-- 
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] Alternatives to DrRacket

[David Storrs]

On Sun, Nov 26, 2017 at 12:43 PM, David Thrane Christiansen
 wrote:
> Hi Stephen,
>
>> I’ve noticed some list members use other editors or IDE’s.
>>
>> I know two big reasons for using a complex tool is it’s stickiness factors;
>> normally a combination of familiarity (hence speed) with a lot of powerful
>> features and non-transportable customisation.
>>
>> Putting stickiness factors aside, what features in other editors/IDE’s
>> would you like to see in DrRacket?

Multiple cursor mode.  cf http://emacsrocks.com/e13.html  I don't use
it all the time but when I use it it's much easier than the
alternatives.


> 2. The macro stepper is extremely handy when it works, and being able to
> inspect syntax objects in the interactions pane is wonderful when the
> macro stepper doesn't work.

Offtopic:  This is the one big feature that I've tried DrRacket for,
but I've never been able to make it work. Everything gets reduced to
lambdas instead of more high-level forms so that long before I
actually see anything useful I get a giant mess.   Maybe I don't
understand it well enough, or maybe there's something I need to do
differently with it?  I was expecting to just keep clicking the 'step'
button; is there any sort of context or etc that I need to establish
first?

-- 
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] Alternatives to DrRacket

[Richard Cobbe]

On Mon, Nov 27, 2017 at 09:48:16AM +, Robby Findler wrote:
> It may help to disable online compilation. (Click on the little circle in
> the bottom to get a menu that lets you disable it.)

Ah!  Thanks for the suggestion; I'll give that a try.

Richard

-- 
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] Alternatives to DrRacket

[Annaia Berry]

I generally use DrRacket for all my Racket dev because it "just works
(tm)". I have sometimes used other editors for it, and the main things I
miss from those usually are autocomplete (DrR has this but it's always been
way too slow for me so I never turn it on), more detailed syntax
highlighting (like royall Spence's examples), rainbow parens, and perhaps
most importantly of all: Parinfer.

Parinfer makes Lisp editing vastly less painful, though DrRacket is pretty
good about visualizing bracket containment so that missing parens at least
are easily spotted usually. restructuring code and so forth though is just
so much more pleasant I find with Parinfer, especially the Atom version's
auto-reformatting (something I miss even in my favorite, VS Code!).

for the most part though, DrRacket always seems to just be "good enough"
that having everything in one easily accessed tool is worth what minor
conveniences I miss out on.

On Mon, Nov 27, 2017 at 11:48 AM, Robby Findler  wrote:

> It may help to disable online compilation. (Click on the little circle in
> the bottom to get a menu that lets you disable it.)
>
> Robby
>
> On Sun, Nov 26, 2017 at 9:21 PM Richard Cobbe  wrote:
>
>> On Sun, Nov 26, 2017 at 03:42:14PM +, Stephen De Gabrielle wrote:
>> > Hi,
>> >
>> > I’ve noticed some list members use other editors or IDE’s.
>> >
>> > I know two big reasons for using a complex tool is it’s stickiness
>> factors;
>> > normally a combination of familiarity (hence speed) with a lot of
>> powerful
>> > features and non-transportable customisation.
>> >
>> > Putting stickiness factors aside, what features in other editors/IDE’s
>> > would you like to see in DrRacket?
>>
>> I generally switch back and forth between Emacs and DrRacket as
>> appropriate
>> for the task at hand.  DrRacket is good for code navigation, but if I'm
>> doing a lot of writing, I generally prefer emacs, largely for reasons that
>> others have mentioned in this thread.
>>
>> There is one particular issue, however, that I haven't seen come up: power
>> usage.  I haven't really investigated what's going on here, but DrRacket
>> drains the battery on my MacBook Pro quite rapidly (last experienced with
>> DrRacket 6.11 on MacOS 10.12.latest).  What's more, it appears to do this
>> even if the app is only open in the background and I'm not actually
>> interacting with it.  So if I don't have access to AC power, I generally
>> close DrRacket and stick with Emacs.
>>
>> If the DrRacket maintainers are interested, I'd be happy to help diagnose
>> the power problem in more detail, as time permits.  However, I don't
>> really
>> know what tests would be useful.  Suggestions welcome!
>>
>> Richard
>>
>> --
>> 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] misterious empty line

[Jos Koot]

Hi Ben,
Your guess seems reasonable.
The empty line does not appear when I put the comment in one long line,
but this is ugly.
Defining the comment outside the definition works well,
so I'll use this hack as follows:
 
@elemtag["rearrangement" "Not important."]

@(define my-comment
 (list
  "Procedure "
  (racket in-permutations)
  " produces a sequence of "
  @elemref["rearrangement" "rearrangements"]
  "."))

 
@interaction[
(require racket)
(define (a)
 (code:comment #,my-comment)
 (in-permutations '(1 2 3)))
(a)]

 
Thanks, Jos 

 
  _  

From: Ben Greenman [mailto:benjaminlgreen...@gmail.com] 
Sent: lunes, 27 de noviembre de 2017 6:44
To: Jos Koot
Cc: Racket Users
Subject: Re: [racket-users] misterious empty line


My guess is that "(define" does something special to figure out where to insert 
newlines in the rendered document.

On Thu, Nov 23, 2017 at 9:13 AM, Jos Koot  wrote:


My code:

#lang scribble/manual

@(require
  scribble/core
  scribble/eval
  racket
  (for-label racket)
  (for-syntax racket))

@elemtag["rearrangement" "Not important."]
@interaction[
(require racket)
(code:comment #,(list "Procedure " (racket in-permutations)
 " produces a sequence of " @elemref["rearrangement" "rearrangements"] "."))
(define (a)
 (code:comment #,(list "Procedure " (racket in-permutations)
 " produces a sequence of " @elemref["rearrangement" "rearrangements"] "."))
 (in-permutations '(1 2 3)))
(a)]

Produces the attached HTML.

Why is there a blank line following the comment within the definition?
The blank line does not appear after the comment preceding the definition.

Windows 7 Home Premium,
DrRacket, version 6.11.0.2--2017-11-12(b54ea8c5b1/a) [3m].
Language: scribble/manual [custom]; memory limit: 4000 MB.

Thanks, Jos


--
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+unsubscribe@
 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] Alternatives to DrRacket

[Robby Findler]

It may help to disable online compilation. (Click on the little circle in
the bottom to get a menu that lets you disable it.)

Robby

On Sun, Nov 26, 2017 at 9:21 PM Richard Cobbe  wrote:

> On Sun, Nov 26, 2017 at 03:42:14PM +, Stephen De Gabrielle wrote:
> > Hi,
> >
> > I’ve noticed some list members use other editors or IDE’s.
> >
> > I know two big reasons for using a complex tool is it’s stickiness
> factors;
> > normally a combination of familiarity (hence speed) with a lot of
> powerful
> > features and non-transportable customisation.
> >
> > Putting stickiness factors aside, what features in other editors/IDE’s
> > would you like to see in DrRacket?
>
> I generally switch back and forth between Emacs and DrRacket as appropriate
> for the task at hand.  DrRacket is good for code navigation, but if I'm
> doing a lot of writing, I generally prefer emacs, largely for reasons that
> others have mentioned in this thread.
>
> There is one particular issue, however, that I haven't seen come up: power
> usage.  I haven't really investigated what's going on here, but DrRacket
> drains the battery on my MacBook Pro quite rapidly (last experienced with
> DrRacket 6.11 on MacOS 10.12.latest).  What's more, it appears to do this
> even if the app is only open in the background and I'm not actually
> interacting with it.  So if I don't have access to AC power, I generally
> close DrRacket and stick with Emacs.
>
> If the DrRacket maintainers are interested, I'd be happy to help diagnose
> the power problem in more detail, as time permits.  However, I don't really
> know what tests would be useful.  Suggestions welcome!
>
> Richard
>
> --
> 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] Alternatives to DrRacket

[Damien MATTEI]

i use emacs with all Scheme implementations and also for Racket,when debugging 
i can use the racket editor that display information about trace calls
but i still modify in emacs and refresh only in DrRacket, in emacs i appeciate 
the syntax highlighting and the search and replace fast short-cuts and because 
i use those features  for a long time.

Damien


Le Sunday 26 November 2017 04:42:14 pm Stephen De Gabrielle, vous avez écrit :
> Hi,
> 
> I’ve noticed some list members use other editors or IDE’s.
> 
> I know two big reasons for using a complex tool is it’s stickiness factors;
> normally a combination of familiarity (hence speed) with a lot of powerful
> features and non-transportable customisation.
> 
> Putting stickiness factors aside, what features in other editors/IDE’s
> would you like to see in DrRacket?
> 
> Kind regards,
> 
> Stephen
> 
> 
> -- 
> Kind regards,
> Stephen
> --
> Ealing (London), UK
> 


-- 
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.