scheme coding help...

Griff <grettke@gmail.com> writes:

>On Mar 27, 9:54 pm, phi50...@yahoo.ca wrote: 

>Ack! It is not supposed to be! DrScheme is really set up to make it
>easy for folks to use. I would be interested to know, what were the
>obstacles for you getting what you need in terms of usability?

Part of the issues this poster is having, I believe, stems from the
PLT's handling of type mismatches, which are considered runtime errors
in PLT Schemes.
 

>It sounds like your primary goal is speed and compactness of compiled
>artifacts. By your criteria, the best folks with whom to speak about
>performing such optimizations are on the PLT discussion list:

>http://www.plt-scheme.org/maillist/

>My take on PLT is that they provide an "all-around best approach" in
>terms of interpreter, language, libraries, ide, documentation, and
>vision. That might not be the right place for your group! But, it is
>right for some folks!

PLT's strengths also serve to make for some confusing weaknesses. While
what you can do in PLT Scheme is vast and powerful, and while DrScheme
serves as a great pedagogical tool, sometimes figuring out how to fit
this whole beast into your workflow takes some effort. For example, I
know that I often see questions about why PLT Scheme is so slow. This
usually comes from people who enjoyed using PLT Scheme to learn Scheme
but who now wish to make faster programs. They do not realize that
mzscheme does JIT compilation and benefits from module encapsulation.
This kind of thing isn't always obvious, simply because there is so much
that PLT Scheme does.
 

>I haven't solved the problem presented by the original poster, but I
>can tell you that on Windows XP Pro with DrScheme v372, a "Hello,
>world." application gets compiled down to 240KB. 5M sounds way too
>big. Here is the code:

>(module hello-world mzscheme
>  (display "Hello, world."))

>put it in a file called "hello-world.ss"

>and compile it with

>mzc --exe hello-world hello-world.ss

I believe the original poster is using some default settings in
DrScheme, IIRC, and with debugging and all the other pieces of
information out there, along with runtime libraries and the like, things
turn out to be rather big. I think this is just a matter of non-obvious
features, since there is almost always more than one way to do something
in PLT Scheme.
--
Aaron Hsu <arcfide@sacrideo.us> | Jabber: arcfide@jabber.org
``Government is the great fiction through which everybody endeavors to
live at the expense of everybody else.'' - Frederic Bastiat

On Sat, 29 Mar 2008 18:22:21 -0500, Aaron Hsu <arcfide@sacrideo.us>
wrote:

>Griff <grettke@gmail.com> writes:
> 
> 
>
>Part of the issues this poster is having, I believe, stems from the
>PLT's handling of type mismatches, which are considered runtime errors
>in PLT Schemes.
> 
> 
> 
> 
>
>PLT's strengths also serve to make for some confusing weaknesses. While
>what you can do in PLT Scheme is vast and powerful, and while DrScheme
>serves as a great pedagogical tool, sometimes figuring out how to fit
>this whole beast into your workflow takes some effort. For example, I
>know that I often see questions about why PLT Scheme is so slow. This
>usually comes from people who enjoyed using PLT Scheme to learn Scheme
>but who now wish to make faster programs. They do not realize that
>mzscheme does JIT compilation and benefits from module encapsulation.
>This kind of thing isn't always obvious, simply because there is so much
>that PLT Scheme does.
> 
> 
> 
> 
> 
> 
>
>I believe the original poster is using some default settings in
>DrScheme, IIRC, and with debugging and all the other pieces of
>information out there, along with runtime libraries and the like, things
>turn out to be rather big. I think this is just a matter of non-obvious
>features, since there is almost always more than one way to do something
>in PLT Scheme.

Very true.  PLT is an excellent learning tool and a good all-around
development platform, but it is quite difficult to figure out how to
create and deliver an optimized program using it.  Much of the
relevant documentation is not included in the default distribution and
must be downloaded separately from the PLT site.

George
--
for email reply remove "/" from address

On Mar 30, 1:19 am, George Neuner <gneuner2/@/comcast.net> wrote:

> Much of the relevant documentation is not included in the default distribu
tion and
> must be downloaded separately from the PLT site.

George are you referring to the relevant documentation on
optimization, or on the documentation in general, that needs to be
downloaded separately?

On Sun, 30 Mar 2008 09:35:52 -0700 (PDT), Griff <grettke@gmail.com>
wrote:

>On Mar 30, 1:19 am, George Neuner <gneuner2/@/comcast.net> wrote:
> 
>
>George are you referring to the relevant documentation on
>optimization, or on the documentation in general, that needs to be
>downloaded separately?

Sorry ... I should have been more specific.

The distribution does not include help desk files for a number of
advanced subjects: compiler, runtime, FFI, GUI framework, web server,
certain of the libraries, etc.  These subjects are (supposed to be)
links to optional doc packages which can be demand download from the
PLT site when referenced.

Writing optimized programs for PLT requires (minimally) reading the
following manuals:

- Inside PLT MzScheme
- PLT mzc: MzScheme Compiler Manual
- PLT Foreign Interface Manual

I can't speak for v372 (the current version), but as of v370 - the
last one I installed - the links for these and a few other help desk
books did nothing at all ... the doc packages had to downloaded and
installed manually (after which the links did work locally).

PDF versions of all the manuals are also available on the PLT site and
they remain manual downloads.



If the situation has changed with the latest version then I apologize
for injecting confusion.

George
--
for email reply remove "/" from address

George Neuner skrev:

> I can't speak for v372 (the current version), but as of v370 - the
> last one I installed - the links for these and a few other help desk
> books did nothing at all ... the doc packages had to downloaded and
> installed manually (after which the links did work locally).

One man's manuals is another's almost automatically.

The are links to the "missing" manuals in the HelpDesk, and
if they are not present, you are presented for a link which
automatically downloads and installs them.

> PDF versions of all the manuals are also available on the PLT site and
> they remain manual downloads.
>
> If the situation has changed with the latest version then I apologize
> for injecting confusion.

An easy way to make sure you have all manuals is to fetch the
"full" version on the prerelease page.

--
Jens Axel Søgaard

On Mon, 31 Mar 2008 17:00:40 +0200, Jens Axel Soegaard
<invalid@soegaard.net> wrote:

>George Neuner skrev:
> 
>
>One man's manuals is another's almost automatically.
>
>The are links to the "missing" manuals in the HelpDesk, and
>if they are not present, you are presented for a link which
>automatically downloads and installs them.

I'll say it again.

Some (not all) of the help desk auto-download links in v370 (at least
for Windows) were broken ... they did not work.

_After_ manually downloading and installing the missing doc packages
those same links worked locally.


>An easy way to make sure you have all manuals is to fetch the
>"full" version on the prerelease page.

I don't use pre-release software so I've never seen this link.

George
--
for email reply remove "/" from address

George Neuner wrote:

> The distribution does not include help desk files for a number of
> advanced subjects: compiler, runtime, FFI, GUI framework, web server,
> certain of the libraries, etc.  These subjects are (supposed to be)
> links to optional doc packages which can be demand download from the
> PLT site when referenced.

Rrr.  I hate systems that involve "on-demand download" - I do lots
of my programming work on my laptop, on the move, and it's not at
all uncommon for me to not be connected to a local network.  I
start using something, I pull down "help" on a particular topic,
and it says "cannot connect to ...." and fails.  I grind my teeth and
say "strike one."  Then I try the man page for the application.  If
that's also missing (or merely useless), strike two.


Bear

George Neuner skrev:
> On Mon, 31 Mar 2008 17:00:40 +0200, Jens Axel Soegaard
> <invalid@soegaard.net> wrote:
> 
>
> I'll say it again.
>
> Some (not all) of the help desk auto-download links in v370 (at least
> for Windows) were broken ... they did not work.

I used v370 for Windows and I can't remember any problems.

--
Jens Axel Søgaaard

Ray Dillinger skrev:
> George Neuner wrote:
> 
>
> Rrr.  I hate systems that involve "on-demand download" - I do lots
> of my programming work on my laptop, on the move, and it's not at
> all uncommon for me to not be connected to a local network.  I
> start using something, I pull down "help" on a particular topic,
> and it says "cannot connect to ...." and fails.  I grind my teeth and
> say "strike one."  Then I try the man page for the application.  If
> that's also missing (or merely useless), strike two.

If memory serves me, on the "Manuals" page in the HelpDesk there
were a "Download all" button.

In the SVN version the HelpDesk has been replaced with browser friendly
documentation.

--
Jens Axel Søgaard

On Mar 29, 4:55 pm, Griff <gret...@gmail.com> wrote:

> I haven't solved the problem presented by the original poster, but I
> can tell you that on Windows XP Pro with DrScheme v372, a "Hello,
> world." application gets compiled down to 240KB.

Ehm.  That's a program twice the length of Shakespeare's "Hamlet"
that prints 13 characters.  Not quite as bad as the proverbial
monkey at a typewriter, but nothing to brag about either.

Andre