Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Jakub Piotr Cłapa]

On 11.08.11 09:25, Eli Barzilay wrote:

If so, then the next
step is to change the layout to:

  Download:  __Macintosh OS X (Intel i386)__
  (this is the version of DrRacket for your system. In rare cases,
you might need a version for a __different system__)


This will damage many more people.


Why? If someone knows what he is doing he will go to the manual download 
list and select the right choice. If he does not then our (educated by 
header/JavaScript sniffing) guess is the best he can hope for.


What are the reasons to not offer the 32bit version as a default on OS 
X? And are fat binaries out of the question?


--
regards,
Jakub Piotr Cłapa
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Shriram Krishnamurthi]

Eli has asked us to wait.  Please do so.  He will reply in more detail
when he gets to a proper computer.

On Thu, Aug 11, 2011 at 3:36 PM, Guillaume Marceau  wrote:
>
>
> On Thu, Aug 11, 2011 at 3:03 PM, Guillaume Marceau 
> wrote:
>> Or we can trust that the Mozilla Foundation's user interface designers has
>> already done the experiment. They have some of the best people of the
>> industry working for them, including Aza Raskin, son of Jef Raskin, one of
>> the original designer of the Macintosh. I see no reason to deviate from
>> their design choice.
>>    [big:]         DrRacket
>>    [almost as large:]   Free Download
>>    [small and grey:]  5.1.2 for Windows, English (US)
>>    [outside of the button, small and light-grey:] All Systems & Languages
>> Shriram, if you want I can email Aza and ask him what experiments they did
>> to arrive at the current design.
>>
>
> This particular design is getting more common around the web.
>
> Apple's iTune download page have a big button that reads "Download Now,"
> then at the bottom of the page they have two small links:
>
>         64-bit editions of Windows Vista or Windows 7 require the iTunes
> 64-bit installer
> and
>         G3 Mac Users
>
> Google Chrome has a big button that read "Download Google Chrome", right
> below they have "It's free and installs in seconds
> For Windows XP, Vista, and 7," then at the bottom of the page, in small:
>
>         Chrome for Mac or Linux · Chrome Beta
>
> Sourceforge have a big button "Download Inkscape-0.48.1…exe", and then below
> "Other Versions, Browse all files"
>
> etc.

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Guillaume Marceau]

On Thu, Aug 11, 2011 at 3:03 PM, Guillaume Marceau 
wrote:
> Or we can trust that the Mozilla Foundation's user interface designers has
> already done the experiment. They have some of the best people of the
> industry working for them, including Aza Raskin, son of Jef Raskin, one of
> the original designer of the Macintosh. I see no reason to deviate from
> their design choice.
>[big:] DrRacket
>[almost as large:]   Free Download
>[small and grey:]  5.1.2 for Windows, English (US)
>[outside of the button, small and light-grey:] All Systems & Languages
> Shriram, if you want I can email Aza and ask him what experiments they did
> to arrive at the current design.
>

This particular design is getting more common around the web.

Apple's iTune download page  have a
big button that reads "Download Now," then at the bottom of the page they
have two small links:

64-bit editions of Windows Vista or Windows 7 require the iTunes
64-bit installer
and
G3 Mac Users

Google Chrome  has a big button that read
"Download Google Chrome", right below they have "It's free and installs in
seconds
For Windows XP, Vista, and 7," then at the bottom of the page, in small:

Chrome for Mac or Linux · Chrome Beta

Sourceforge  have a big button
"Download Inkscape-0.48.1…exe", and then below "Other Versions, Browse all
files"

etc.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Guillaume Marceau]

Or we can trust that the Mozilla Foundation's user interface designers has
already done the experiment. They have some of the best people of the
industry working for them, including Aza Raskin, son of Jef Raskin, one of
the original designer of the Macintosh. I see no reason to deviate from
their design choice.

   [big:] DrRacket
   [almost as large:]   Free Download
   [small and grey:]  5.1.2 for Windows, English (US)

   [outside of the button, small and light-grey:] All Systems & Languages

Shriram, if you want I can email Aza and ask him what experiments they did
to arrive at the current design.


On Thu, Aug 11, 2011 at 2:53 PM, Shriram Krishnamurthi wrote:

> We also have an extensive audience on the users list and in our
> individual departments.  So it would be easy to circulate a draft Web
> page (no fancy download or even formatting) that simply says, "I'm
> guessing you are using a ... -- is this correct?" and get lots of
> people to test (and get more details from those who say no).  We
> should crowdsource this for maximum benefit.
>
> Shriram
>
> On Thu, Aug 11, 2011 at 2:22 PM, Robby Findler
>  wrote:
> > I'd be happy to comment on drafts too, if that's useful.
> >
> > Robby
> >
> > On Thu, Aug 11, 2011 at 1:20 PM, Matthias Felleisen
> >  wrote:
> >>
> >> Guillaum, why don't you work out a concrete plan, especially the wording
> of the messages to the downloader, and submit it to ELi for review. He will
> implement a version of it. Thanks -- Matthias
> >>
> >>
> >> _
> >>  For list-related administrative tasks:
> >>  http://lists.racket-lang.org/listinfo/dev
> >>
> >
> > _
> >  For list-related administrative tasks:
> >  http://lists.racket-lang.org/listinfo/dev
>
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Eli Barzilay]

It's best to avoid working on anything concrete until I can write a
proper reply since there are more issues here.  (Note: this is not an
objection to an improvement, but an attempt to avoid the kind of
damage I mnetioned earlier.

On 2011-08-11, Matthias Felleisen  wrote:
>
> Guillaum, why don't you work out a concrete plan, especially the wording of
> the messages to the downloader, and submit it to ELi for review. He will
> implement a version of it. Thanks -- Matthias
>
>
> _
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/dev
>


-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
  http://www.barzilay.org/ Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Shriram Krishnamurthi]

We also have an extensive audience on the users list and in our
individual departments.  So it would be easy to circulate a draft Web
page (no fancy download or even formatting) that simply says, "I'm
guessing you are using a ... -- is this correct?" and get lots of
people to test (and get more details from those who say no).  We
should crowdsource this for maximum benefit.

Shriram

On Thu, Aug 11, 2011 at 2:22 PM, Robby Findler
 wrote:
> I'd be happy to comment on drafts too, if that's useful.
>
> Robby
>
> On Thu, Aug 11, 2011 at 1:20 PM, Matthias Felleisen
>  wrote:
>>
>> Guillaum, why don't you work out a concrete plan, especially the wording of 
>> the messages to the downloader, and submit it to ELi for review. He will 
>> implement a version of it. Thanks -- Matthias
>>
>>
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>>
>
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Robby Findler]

I'd be happy to comment on drafts too, if that's useful.

Robby

On Thu, Aug 11, 2011 at 1:20 PM, Matthias Felleisen
 wrote:
>
> Guillaum, why don't you work out a concrete plan, especially the wording of 
> the messages to the downloader, and submit it to ELi for review. He will 
> implement a version of it. Thanks -- Matthias
>
>
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Matthias Felleisen]

Guillaum, why don't you work out a concrete plan, especially the wording of the 
messages to the downloader, and submit it to ELi for review. He will implement 
a version of it. Thanks -- Matthias


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Robby Findler]

Yes, my sentiments exactly.

Robby

On Thu, Aug 11, 2011 at 1:13 PM, Matthias Felleisen
 wrote:
>
> I am happy to see that we are looking for solutions to a problem.
>
> I think we should use everything we can to make the best possible guess. Then 
> we should use English language to inform people that we made a best possible 
> guess and that there are alternatives. But this language must be extremely 
> non-scary to BEGINNERS.
>
>
>
> On Aug 11, 2011, at 2:10 PM, Robby Findler wrote:
>
>> I think that maybe, given this particular choice, it makes more sense
>> to say, on the web page, "We believe you are on a mac; the 32bit
>> version is the one you want, unless you're sure you want the 64bit
>> version, which is here. other versions there" which a touch of good
>> design and better wording, I think that would be better than relying
>> on adobe not doing software development.
>>
>> Robby
>>
>> On Thu, Aug 11, 2011 at 12:32 PM, Guillaume Marceau  
>> wrote:
>>> On Thu, Aug 11, 2011 at 1:21 PM, Robby Findler
>>>  wrote:

 On Thu, Aug 11, 2011 at 12:16 PM, Guillaume Marceau  
 wrote:
> In the ambiguous cases, you can get additional information by checking for
> flash. Because Adobe doesn't support flash player on x64 browsers, if
> detection is successful then it is definitely a 32 bit browser, if not, 
> then
> the request came from either a 32 bit browser without flash plugin or 
> from a
> 64 bit browser.

 That seems like an unfortunate thing to rely on.
>>>
>>> Such is life in the stormy world of web development. Just ask Danny
>>> about the ridiculous things he has to do to make WeScheme work on the
>>> different browsers.
>>>
>>
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>
>

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Matthias Felleisen]

I am happy to see that we are looking for solutions to a problem. 

I think we should use everything we can to make the best possible guess. Then 
we should use English language to inform people that we made a best possible 
guess and that there are alternatives. But this language must be extremely 
non-scary to BEGINNERS. 



On Aug 11, 2011, at 2:10 PM, Robby Findler wrote:

> I think that maybe, given this particular choice, it makes more sense
> to say, on the web page, "We believe you are on a mac; the 32bit
> version is the one you want, unless you're sure you want the 64bit
> version, which is here. other versions there" which a touch of good
> design and better wording, I think that would be better than relying
> on adobe not doing software development.
> 
> Robby
> 
> On Thu, Aug 11, 2011 at 12:32 PM, Guillaume Marceau  
> wrote:
>> On Thu, Aug 11, 2011 at 1:21 PM, Robby Findler
>>  wrote:
>>> 
>>> On Thu, Aug 11, 2011 at 12:16 PM, Guillaume Marceau  
>>> wrote:
 In the ambiguous cases, you can get additional information by checking for
 flash. Because Adobe doesn't support flash player on x64 browsers, if
 detection is successful then it is definitely a 32 bit browser, if not, 
 then
 the request came from either a 32 bit browser without flash plugin or from 
 a
 64 bit browser.
>>> 
>>> That seems like an unfortunate thing to rely on.
>> 
>> Such is life in the stormy world of web development. Just ask Danny
>> about the ridiculous things he has to do to make WeScheme work on the
>> different browsers.
>> 
> 
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Robby Findler]

I think that maybe, given this particular choice, it makes more sense
to say, on the web page, "We believe you are on a mac; the 32bit
version is the one you want, unless you're sure you want the 64bit
version, which is here. other versions there" which a touch of good
design and better wording, I think that would be better than relying
on adobe not doing software development.

Robby

On Thu, Aug 11, 2011 at 12:32 PM, Guillaume Marceau  wrote:
> On Thu, Aug 11, 2011 at 1:21 PM, Robby Findler
>  wrote:
>>
>> On Thu, Aug 11, 2011 at 12:16 PM, Guillaume Marceau  
>> wrote:
>> > In the ambiguous cases, you can get additional information by checking for
>> > flash. Because Adobe doesn't support flash player on x64 browsers, if
>> > detection is successful then it is definitely a 32 bit browser, if not, 
>> > then
>> > the request came from either a 32 bit browser without flash plugin or from 
>> > a
>> > 64 bit browser.
>>
>> That seems like an unfortunate thing to rely on.
>
> Such is life in the stormy world of web development. Just ask Danny
> about the ridiculous things he has to do to make WeScheme work on the
> different browsers.
>

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Guillaume Marceau]

On Thu, Aug 11, 2011 at 1:21 PM, Robby Findler
 wrote:
>
> On Thu, Aug 11, 2011 at 12:16 PM, Guillaume Marceau  
> wrote:
> > In the ambiguous cases, you can get additional information by checking for
> > flash. Because Adobe doesn't support flash player on x64 browsers, if
> > detection is successful then it is definitely a 32 bit browser, if not, then
> > the request came from either a 32 bit browser without flash plugin or from a
> > 64 bit browser.
>
> That seems like an unfortunate thing to rely on.

Such is life in the stormy world of web development. Just ask Danny
about the ridiculous things he has to do to make WeScheme work on the
different browsers.

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Robby Findler]

On Thu, Aug 11, 2011 at 12:16 PM, Guillaume Marceau  wrote:
> In the ambiguous cases, you can get additional information by checking for
> flash. Because Adobe doesn't support flash player on x64 browsers, if
> detection is successful then it is definitely a 32 bit browser, if not, then
> the request came from either a 32 bit browser without flash plugin or from a
> 64 bit browser.

That seems like an unfortunate thing to rely on.

Robby

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Guillaume Marceau]

On Thu, Aug 11, 2011 at 3:25 AM, Eli Barzilay  wrote:
> On Aug 10, 2011, at 11:33 PM, Guillaume Marceau 
wrote:
>> Does the combo box auto detect the
>> downloader's platform for the User-Agent header.
>
> Yes, in some cases when it's possible to make a guess.
>

I found this Stackoverflow article:


http://stackoverflow.com/questions/1741933/detect-64-bit-or-32-bit-windows-from-user-agent-or-javascript

which says that the following code

deployJava.isWin64OS = function() {
   return navigator.userAgent.indexOf('WOW64')>-1 ||
window.navigator.platform=='Win64';
};


will return one of these:

64 bit MacOS + 64 bit Safari or 32 bit Chrome:
window.navigator.platform=MacIntel

32 bit windows + safari:
window.navigator.platform=Win32

64 bit Windows + 64 bit IE:
window.navigator.platform=Win64
window.navigator.cpuClass=x64

64 bit Windows + 32 bit IE:
window.navigator.platform=Win32
window.navigator.cpuClass=x86

64 bit Windows + 32 Firefox (or Chrome):
window.navigator.platform=Win32

32 bit linux mint (i686) + firefox:
window.navigator.platform=Linux i686

64 bit Ubuntu (x86_64) + 32 bit Chrome:
window.navigator.platform=Linux i686

64 bit Ubuntu + 64 bit Epiphany:
window.navigator.platform=Linux x86_64

In the ambiguous cases, you can get additional information by checking for
flash. Because Adobe doesn't support flash player on x64 browsers, if
detection is successful then it is definitely a 32 bit browser, if not, then
the request came from either a 32 bit browser without flash plugin or from a
64 bit browser.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Kevin Tew]

look at the firefox download page for an example:
There is a nice huge pretty button that is the download for your current 
platform.
Below the big button there is a small link that says "All Systems & 
Languages " which links 
to the matrix of all possible downloads.


I think http://www.mozilla.com/ is an excellent landing page for "Here, 
Get Our Stuff".


Kevin

On 08/11/2011 10:48 AM, Matthias Felleisen wrote:

His answer was inappropriate. Our goal must be to understand
problems posed, check relevance, figure out a solution. There
is no other default mode.



On Aug 11, 2011, at 8:54 AM, Jay McCarthy wrote:


Maybe Eli is saying that 64bit is really the better default, given new
OS X defaults.

Jay

On Thu, Aug 11, 2011 at 6:23 AM, Robby Findler
  wrote:

Why would it damage more people?

I think it makes sense to put on the first page some kind of an
indication that "this is what we guess your machine is; if you don't
know, try this one first". Perhaps not Guillaume's exact words, but
something that would help this person.

Robby

On Thu, Aug 11, 2011 at 2:25 AM, Eli Barzilay  wrote:

On Aug 10, 2011, at 11:33 PM, Guillaume Marceau  wrote:

Does the combo box auto detect the
downloader's platform for the User-Agent header.

Yes, in some cases when it's possible to make a guess.



If so, then the next
step is to change the layout to:

  Download:  __Macintosh OS X (Intel i386)__
  (this is the version of DrRacket for your system. In rare cases,
you might need a version for a __different system__)

This will damage many more people.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev



--
Jay McCarthy
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


_
   For list-related administrative tasks:
   http://lists.racket-lang.org/listinfo/dev


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Matthias Felleisen]

His answer was inappropriate. Our goal must be to understand
problems posed, check relevance, figure out a solution. There
is no other default mode. 



On Aug 11, 2011, at 8:54 AM, Jay McCarthy wrote:

> Maybe Eli is saying that 64bit is really the better default, given new
> OS X defaults.
> 
> Jay
> 
> On Thu, Aug 11, 2011 at 6:23 AM, Robby Findler
>  wrote:
>> Why would it damage more people?
>> 
>> I think it makes sense to put on the first page some kind of an
>> indication that "this is what we guess your machine is; if you don't
>> know, try this one first". Perhaps not Guillaume's exact words, but
>> something that would help this person.
>> 
>> Robby
>> 
>> On Thu, Aug 11, 2011 at 2:25 AM, Eli Barzilay  wrote:
>>> On Aug 10, 2011, at 11:33 PM, Guillaume Marceau  wrote:
 Does the combo box auto detect the
 downloader's platform for the User-Agent header.
>>> 
>>> Yes, in some cases when it's possible to make a guess.
>>> 
>>> 
 If so, then the next
 step is to change the layout to:
 
  Download:  __Macintosh OS X (Intel i386)__
  (this is the version of DrRacket for your system. In rare cases,
 you might need a version for a __different system__)
>>> 
>>> This will damage many more people.
>>> _
>>>  For list-related administrative tasks:
>>>  http://lists.racket-lang.org/listinfo/dev
>>> 
>> 
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
> 
> 
> 
> -- 
> Jay McCarthy 
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
> 
> "The glory of God is Intelligence" - D&C 93
> 
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [racket] pretty-big->#lang (was: External connection toFinndesign Liitin)

[Robby Findler]

On Thu, Aug 11, 2011 at 8:56 AM, Sam Tobin-Hochstadt  wrote:
> On Thu, Aug 11, 2011 at 9:38 AM, Robby Findler
>  wrote:
>> On Thu, Aug 11, 2011 at 8:25 AM, Sam Tobin-Hochstadt  
>> wrote:
>>> On Thu, Aug 11, 2011 at 9:20 AM, Robby Findler
>>>  wrote:
>>>
> How problematic would it be if the DrRacket interactions window didn't
> make the namespace it uses for evaluation available to the expressions
> being evaluated?

 How would that work? Could drracket compile the expression in the
 namespace that has the insides of the module and then, when evaluating
 it, set the namespace back to the one in effect while running the
 definitions window? (That seems a bit strange; I don't have a good
 idea how it would work.)
>>>
>>> What I was thinking was more along the lines of disconnecting the
>>> value of `current-namespace' that DrRacket sees from the value that
>>> the user program sees -- in other words, having that parameter not be
>>> part of the underlying shared portion of Racket like `+', but more
>>> like the things that DrRacket doesn't share, like its inspector.  I
>>> think that would require lower-level changes, though.
>>
>> Well, lower-level is not a complete magic wand here :). I think there
>> would have to be some way to understand what you expect the
>> lower-level to be doing and then, after that, figure out what level
>> that fits best at.
>
> Yes, I agree.
>
>> Like having two versions of current-namespace: I think what you're
>> saying is that drracket should do something like this:
>>
>>  (parameterize ([current-namespace repl-namespace-with-all-the-goodies])
>>    (eval `(parameterize ([current-namespace
>> ,the-actual-likely-empty-users-namespace])
>>             ,users-program)))
>>
>> maybe?
>
> Yeah, that seems like a nice and simple way of doing it.  Another way would 
> be:
>
> (parameterize ([current-eval
>                      (let ([old (current-eval)]
>                            [ns (current-namespace)])
>                        (lambda (e) (parameterize ([current-namespace
> ns]) (old e])
>  (eval users-program repl-namespace/goodies))
>
> Which is basically just a version of the two-argument `eval' that
> doesn't do the parameterization.
>
> The lower-level change is, it seems, not needed, since this is already
> easily expressible.

If you wanted to experiment with these three variants to try to
understand which one works best, etc., that would be very welcome. (My
guess is that there are some subtle differences between these and so
I'm not sure I'd want to just pick one and stick it in without someone
trying things out for a while. There are test suites (specifically the
'repl-test.rkt' file in tests/drracket, but it probably needs more
tests that try to break things with the knowledge of which one of
these options does what.)

Robby

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [racket] pretty-big->#lang (was: External connection toFinndesign Liitin)

[Sam Tobin-Hochstadt]

On Thu, Aug 11, 2011 at 9:38 AM, Robby Findler
 wrote:
> On Thu, Aug 11, 2011 at 8:25 AM, Sam Tobin-Hochstadt  
> wrote:
>> On Thu, Aug 11, 2011 at 9:20 AM, Robby Findler
>>  wrote:
>>
 How problematic would it be if the DrRacket interactions window didn't
 make the namespace it uses for evaluation available to the expressions
 being evaluated?
>>>
>>> How would that work? Could drracket compile the expression in the
>>> namespace that has the insides of the module and then, when evaluating
>>> it, set the namespace back to the one in effect while running the
>>> definitions window? (That seems a bit strange; I don't have a good
>>> idea how it would work.)
>>
>> What I was thinking was more along the lines of disconnecting the
>> value of `current-namespace' that DrRacket sees from the value that
>> the user program sees -- in other words, having that parameter not be
>> part of the underlying shared portion of Racket like `+', but more
>> like the things that DrRacket doesn't share, like its inspector.  I
>> think that would require lower-level changes, though.
>
> Well, lower-level is not a complete magic wand here :). I think there
> would have to be some way to understand what you expect the
> lower-level to be doing and then, after that, figure out what level
> that fits best at.

Yes, I agree.

> Like having two versions of current-namespace: I think what you're
> saying is that drracket should do something like this:
>
>  (parameterize ([current-namespace repl-namespace-with-all-the-goodies])
>    (eval `(parameterize ([current-namespace
> ,the-actual-likely-empty-users-namespace])
>             ,users-program)))
>
> maybe?

Yeah, that seems like a nice and simple way of doing it.  Another way would be:

(parameterize ([current-eval
  (let ([old (current-eval)]
[ns (current-namespace)])
(lambda (e) (parameterize ([current-namespace
ns]) (old e])
 (eval users-program repl-namespace/goodies))

Which is basically just a version of the two-argument `eval' that
doesn't do the parameterization.

The lower-level change is, it seems, not needed, since this is already
easily expressible.
-- 
sam th
sa...@ccs.neu.edu

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [racket] pretty-big->#lang (was: External connection toFinndesign Liitin)

[Robby Findler]

On Thu, Aug 11, 2011 at 8:25 AM, Sam Tobin-Hochstadt  wrote:
> On Thu, Aug 11, 2011 at 9:20 AM, Robby Findler
>  wrote:
>
>>> How problematic would it be if the DrRacket interactions window didn't
>>> make the namespace it uses for evaluation available to the expressions
>>> being evaluated?
>>
>> How would that work? Could drracket compile the expression in the
>> namespace that has the insides of the module and then, when evaluating
>> it, set the namespace back to the one in effect while running the
>> definitions window? (That seems a bit strange; I don't have a good
>> idea how it would work.)
>
> What I was thinking was more along the lines of disconnecting the
> value of `current-namespace' that DrRacket sees from the value that
> the user program sees -- in other words, having that parameter not be
> part of the underlying shared portion of Racket like `+', but more
> like the things that DrRacket doesn't share, like its inspector.  I
> think that would require lower-level changes, though.

Well, lower-level is not a complete magic wand here :). I think there
would have to be some way to understand what you expect the
lower-level to be doing and then, after that, figure out what level
that fits best at.

Like having two versions of current-namespace: I think what you're
saying is that drracket should do something like this:

  (parameterize ([current-namespace repl-namespace-with-all-the-goodies])
(eval `(parameterize ([current-namespace
,the-actual-likely-empty-users-namespace])
 ,users-program)))

maybe?

Robby

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [racket] pretty-big->#lang (was: External connection toFinndesign Liitin)

[Sam Tobin-Hochstadt]

On Thu, Aug 11, 2011 at 9:20 AM, Robby Findler
 wrote:

>> How problematic would it be if the DrRacket interactions window didn't
>> make the namespace it uses for evaluation available to the expressions
>> being evaluated?
>
> How would that work? Could drracket compile the expression in the
> namespace that has the insides of the module and then, when evaluating
> it, set the namespace back to the one in effect while running the
> definitions window? (That seems a bit strange; I don't have a good
> idea how it would work.)

What I was thinking was more along the lines of disconnecting the
value of `current-namespace' that DrRacket sees from the value that
the user program sees -- in other words, having that parameter not be
part of the underlying shared portion of Racket like `+', but more
like the things that DrRacket doesn't share, like its inspector.  I
think that would require lower-level changes, though.

-- 
sam th
sa...@ccs.neu.edu
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [racket] pretty-big->#lang (was: External connection toFinndesign Liitin)

[Robby Findler]

On Thu, Aug 11, 2011 at 8:17 AM, Sam Tobin-Hochstadt  wrote:
> [switch to dev]
>
> On Thu, Aug 11, 2011 at 12:11 AM, Matthew Flatt  wrote:
>
>> DrRacket's interactions window has to use `eval' in the sense that it
>> reads an expression to evaluate and then passes it on to the program
>> for an answer. When you run a module in DrRacket, the interactions
>> window treats expressions as being in the language of the module body.
>> Furthermore, since the interactions window works through `eval', it
>> turns out that DrRacket sets `eval' globally to use the module's
>> language while evaluating expressions in the interactions window. In
>> Racket terminology, DrRacket sets the `current-namespace' parameter to
>> the module's namespace when it initializes the interactions window.
>
> I think this paragraph (the rest is great!)

The rest is really excellent, I agree. (I even liked this part :)

>  points to the key problem.
>  The fact that insufficiently-namespaced uses of `eval' work in the
> interactions window leads people to the wrong conclusion about how
> things work in general.  Also, whereas everything else has a good
> reason given, this behavior is described with "it turns out that" and
> an explanation about the implementation.
>
> How problematic would it be if the DrRacket interactions window didn't
> make the namespace it uses for evaluation available to the expressions
> being evaluated?

How would that work? Could drracket compile the expression in the
namespace that has the insides of the module and then, when evaluating
it, set the namespace back to the one in effect while running the
definitions window? (That seems a bit strange; I don't have a good
idea how it would work.)

Robby

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [racket] pretty-big->#lang (was: External connection toFinndesign Liitin)

[Sam Tobin-Hochstadt]

[switch to dev]

On Thu, Aug 11, 2011 at 12:11 AM, Matthew Flatt  wrote:

> DrRacket's interactions window has to use `eval' in the sense that it
> reads an expression to evaluate and then passes it on to the program
> for an answer. When you run a module in DrRacket, the interactions
> window treats expressions as being in the language of the module body.
> Furthermore, since the interactions window works through `eval', it
> turns out that DrRacket sets `eval' globally to use the module's
> language while evaluating expressions in the interactions window. In
> Racket terminology, DrRacket sets the `current-namespace' parameter to
> the module's namespace when it initializes the interactions window.

I think this paragraph (the rest is great!) points to the key problem.
 The fact that insufficiently-namespaced uses of `eval' work in the
interactions window leads people to the wrong conclusion about how
things work in general.  Also, whereas everything else has a good
reason given, this behavior is described with "it turns out that" and
an explanation about the implementation.

How problematic would it be if the DrRacket interactions window didn't
make the namespace it uses for evaluation available to the expressions
being evaluated?
-- 
sam th
sa...@ccs.neu.edu
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Robby Findler]

I'm not completely clear on exactly how things are working with Lion,
but it seems unlikely that 64 bit is a good default at this stage.

Robby

On Thu, Aug 11, 2011 at 7:54 AM, Jay McCarthy  wrote:
> Maybe Eli is saying that 64bit is really the better default, given new
> OS X defaults.
>
> Jay
>
> On Thu, Aug 11, 2011 at 6:23 AM, Robby Findler
>  wrote:
>> Why would it damage more people?
>>
>> I think it makes sense to put on the first page some kind of an
>> indication that "this is what we guess your machine is; if you don't
>> know, try this one first". Perhaps not Guillaume's exact words, but
>> something that would help this person.
>>
>> Robby
>>
>> On Thu, Aug 11, 2011 at 2:25 AM, Eli Barzilay  wrote:
>>> On Aug 10, 2011, at 11:33 PM, Guillaume Marceau  wrote:
 Does the combo box auto detect the
 downloader's platform for the User-Agent header.
>>>
>>> Yes, in some cases when it's possible to make a guess.
>>>
>>>
 If so, then the next
 step is to change the layout to:

      Download:  __Macintosh OS X (Intel i386)__
      (this is the version of DrRacket for your system. In rare cases,
 you might need a version for a __different system__)
>>>
>>> This will damage many more people.
>>> _
>>>  For list-related administrative tasks:
>>>  http://lists.racket-lang.org/listinfo/dev
>>>
>>
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>
>
>
> --
> Jay McCarthy 
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Jay McCarthy]

Maybe Eli is saying that 64bit is really the better default, given new
OS X defaults.

Jay

On Thu, Aug 11, 2011 at 6:23 AM, Robby Findler
 wrote:
> Why would it damage more people?
>
> I think it makes sense to put on the first page some kind of an
> indication that "this is what we guess your machine is; if you don't
> know, try this one first". Perhaps not Guillaume's exact words, but
> something that would help this person.
>
> Robby
>
> On Thu, Aug 11, 2011 at 2:25 AM, Eli Barzilay  wrote:
>> On Aug 10, 2011, at 11:33 PM, Guillaume Marceau  wrote:
>>> Does the combo box auto detect the
>>> downloader's platform for the User-Agent header.
>>
>> Yes, in some cases when it's possible to make a guess.
>>
>>
>>> If so, then the next
>>> step is to change the layout to:
>>>
>>>      Download:  __Macintosh OS X (Intel i386)__
>>>      (this is the version of DrRacket for your system. In rare cases,
>>> you might need a version for a __different system__)
>>
>> This will damage many more people.
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>>
>
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Robby Findler]

Why would it damage more people?

I think it makes sense to put on the first page some kind of an
indication that "this is what we guess your machine is; if you don't
know, try this one first". Perhaps not Guillaume's exact words, but
something that would help this person.

Robby

On Thu, Aug 11, 2011 at 2:25 AM, Eli Barzilay  wrote:
> On Aug 10, 2011, at 11:33 PM, Guillaume Marceau  wrote:
>> Does the combo box auto detect the
>> downloader's platform for the User-Agent header.
>
> Yes, in some cases when it's possible to make a guess.
>
>
>> If so, then the next
>> step is to change the layout to:
>>
>>      Download:  __Macintosh OS X (Intel i386)__
>>      (this is the version of DrRacket for your system. In rare cases,
>> you might need a version for a __different system__)
>
> This will damage many more people.
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] strange/wrong placement and sizing in racket/gui

[Marijn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/21/11 09:50, Marijn wrote:
> On 06/20/11 18:29, Matthew Flatt wrote:
>> I think I've found the problem and pushed a fix.
> 
> Thanks for the quick fix Matthew! 1) 2) and 3) are now working fine
> :) but I do believe borders are still broken. For example:
> 
> 
> #lang racket/gui
> 
> (define root (new frame% (label "Label")))
> 
> (define vp (new vertical-panel% (parent root) (vert-margin 5) (style
> '(border
> 
> (define vp2 (new vertical-panel% (parent vp) (horiz-margin 5) (style
> '(border
> 
> (define vp3 (new vertical-panel% (parent vp2) (vert-margin 5) (style
> '(border
> 
> (define btn (new button% (parent vp3) (label "button") (horiz-margin
> 5)))
> 
> (send root show #t)
> 
> 
> produces the attached window with just a button, but no borders for
> any of the panels...
> 
> Marijn

The above is still valid with yesterday's git (see original mail for
image attachment).

Marijn

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5DyQcACgkQp/VmCx0OL2xcUgCgnQzryZY/1mw9NCny0JiA6DN5
/zgAoLgg2kACqajFD/VinfS6RoFXaHL6
=XmUg
-END PGP SIGNATURE-
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Downloading DrRacket for Mac is hard?

[Eli Barzilay]

On Aug 10, 2011, at 11:33 PM, Guillaume Marceau  wrote:
> Does the combo box auto detect the
> downloader's platform for the User-Agent header.

Yes, in some cases when it's possible to make a guess.


> If so, then the next
> step is to change the layout to:
> 
>  Download:  __Macintosh OS X (Intel i386)__
>  (this is the version of DrRacket for your system. In rare cases,
> you might need a version for a __different system__)

This will damage many more people.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev