[Caml-list] Teaching ocaml programming
Andrej Bauer
which we will use ocaml to implement mini-languages. And once again I
face the question: which programming environment should we use?
I have so far tried to use (under Windows)
1. cygwin + ocaml + XEmacs
2. Eclipse + OcaIDE
The second solution worked better than the first, for the simple reason
that XEmacs is a complete mystery to students. They really, really hate
it. But even with the second soltion we had a lot of trouble, because
Eclipse is really complicated, and OcaIDE is sort of experimental and
not so good under Windows, so the whole setup was confusing and fragile.
The requirements are very simple:
1. easy access to toplevel (with line-editing)
2. editor which can send stuff to toplevel, points to errors in source
code, and is not Emacs.
Any ideas what to do? We have dual-boot machines (Windows + Ubuntu).
Best regards,
Andrej
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Lukasz Stafiniak
editor? (e.g. with C-c, C-v editing shortcuts etc.) This shouldn't be
difficult.
On Fri, Sep 26, 2008 at 1:30 PM, Andrej Bauer
<Andrej...@fmf.uni-lj.si> wrote:
> Once again I am teaching a course on theory of programming languages in
> which we will use ocaml to implement mini-languages. And once again I face
> the question: which programming environment should we use?
>
> I have so far tried to use (under Windows)
> 1. cygwin + ocaml + XEmacs
> 2. Eclipse + OcaIDE
>
_______________________________________________
Brighten Godfrey
choice. It is a clean, intuitive, but sufficiently powerful editor.
Emacs always left me annoyed.
I use, on a daily basis, a small script which acts as a front-end to
`make' and automatically points you to the error in the code in
nedit, highlighting the characters that the ocaml compiler complains
about. It uses the existing nedit window if you have the file open
already, or else opens it for you. The script also works with gcc
instead of ocaml, and (though I can't vouch for it much) gvim instead
of nedit. So my typical development environment consists of nedit
and a shell in which I compile via the script.
If anyone is interested, I'd be happy to share this.
I guess the main question would be integrating the toplevel with
nedit. I imagine there are a number of ways to do this, depending on
your needs. You might be able to put something together using
nedit's scripting language, or just do something entirely external to
the editor.
~Brighten
Mehdi Dogguy
Andrej Bauer wrote:
> How can there be no easy to use interface?! This is pathetic.
>
> Python has IDLE. Scheme has drscheme. Java has drjava.
>
And OCaml has Emacs :)
--
Mehdi Dogguy
http://www.pps.jussieu.fr/~dogguy
Hugo Ferreira
Andrej Bauer wrote:
> Once again I am teaching a course on theory of programming languages in
> which we will use ocaml to implement mini-languages. And once again I
> face the question: which programming environment should we use?
>
> I have so far tried to use (under Windows)
> 1. cygwin + ocaml + XEmacs
> 2. Eclipse + OcaIDE
>
> The second solution worked better than the first, for the simple reason
> that XEmacs is a complete mystery to students. They really, really hate
> it. But even with the second soltion we had a lot of trouble, because
> Eclipse is really complicated, and OcaIDE is sort of experimental and
> not so good under Windows, so the whole setup was confusing and fragile.
>
I am a satisfied user of Eclipse + OcaIDE on Ubuntu (64bit).
Considering I am (still) a "newbie" in regards to Ocaml and functional
programming in general, and have a allergy towards emacs, vi and
friends, I would urge you to reconsider OcaIDE + Ubuntu.
To make things simpler you may:
0. Use ocamlbuild projects only.
1. Prepare ocamlbuild files (tags and myocamlbuild) if necessary.
2. Provide a workspace with an example project ready for compilation.
3. Let the students use only one project with various source files.
Point (0) will significantly ease the students experience if they
need not configure any build files. Points (1) and (2) allow you to
add references to used modules, libraries, etc. All the students
do is create a new file, compile and execute.
Point (3) is easy because students need only add a single entry in
the project properties dialogue box (Project targets). They need
only then point and click on the executable to execute and/or debug.
My 2 cents.
HTHs,
Hugo F.
Hugo Ferreira
> Hugo Ferreira wrote:
>> To make things simpler you may:
>> 0. Use ocamlbuild projects only.
>> 1. Prepare ocamlbuild files (tags and myocamlbuild) if necessary.
>> 2. Provide a workspace with an example project ready for compilation.
>> 3. Let the students use only one project with various source files.
>
> because the trick with symbolic links to executables does not work.
Yes, I am aware of this. Seen the reports in the forum.
> Has
> this been fixed yet? (Also, ocamlbuild assumes bash is in the path, also
> under Windows.)
Not that I am aware of. Their is a version that has *not* been
put up onto the update site [1]. Maybe this may have additional
corrections.
Please note that I am proposing you use Ubuntu because you mentioned
dual boot machines:
"Any ideas what to do? We have dual-boot machines (Windows + Ubuntu)."
BTW, I just remembered that I use GODI. Don't know if that is possible
for you.
Regards,
Hugo F.
http://ocaml.eclipse.free.fr/files/Ocaml_1.2.3.jar
>
> Best regards,
>
> Andrej
Peng Zang
Hash: SHA1
If you have dual-boot machines, why not try Ocaml + Emacs + tuareg-mode in
Ubuntu?
You can install tuareg-mode globally so that no one has to touch a .emacs or
know about it. If it's the keyboard shortcuts that students are not used to,
they can 1) deal or 2) you can remap some common shortcuts and wrap it in a
shell script so they run Emacs-for-class instead of standard Emacs.
Personally, I think they should just deal. A little exposure to a
non-Windows environment, a little broadening of horizons, all good stuff.
When I took a programming languages class at UIUC, that is how we learned
OCaml. I found it quite easy to pick up. Emacs has the best toplevel
integration with OCaml and it sounds like you want to make heavy use of it.
Peng
PS. I just looked at IDLE and Emacs + OCaml blows it out of the water. I
swear IDLE is like a mini-subset of Emacs. Even the keyboard shortcuts are
the same. If you like IDLE, Emacs + OCaml can only be better.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFI3PHDfIRcEFL/JewRAsarAKDPPPcNc2WJcPAlu5amtkrH9PmGUwCgm2mP
BrUDh1ukb4mG1HaLC+9Se68=
=u7Sx
-----END PGP SIGNATURE-----
Richard Jones
> My teaching asistant showed the students how to do this, but it was only
> partially successful, not to mention that this required extra
> configuration. _Any_ initial configuration is a big pain, even just
> putting a line in .emacs is a challenge ("Where is this file?", "How can
> it have just an extension and no name?", "Why is the extension longer
> than three letters", etc.)
I think I may have suggested this the last time, but is some sort of
bootable live CD / live USB key an option? Our livecd-creator tool is
especially flexible: you could build a live CD / key which has all the
right packages installed and all the configuration files in the right
place and starts up the editor of your choice when they log in.
http://www-128.ibm.com/developerworks/linux/library/l-fedora-livecd/index.html
http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo
Persistence (of files in the project) is a problem but maybe they can
be encouraged to save project files to a network share or on to a USB
key.
Rich.
--
Richard Jones
Red Hat
Peng Zang
Hash: SHA1
You know, I love that idea. I've been meaning to use it for some of my
projects and keep forgetting about it. Thanks for reminding me,
Peng
On Friday 26 September 2008 10:31:40 am Richard Jones wrote:
> On Fri, Sep 26, 2008 at 01:52:33PM +0200, Andrej Bauer wrote:
> > My teaching asistant showed the students how to do this, but it was only
> > partially successful, not to mention that this required extra
> > configuration. _Any_ initial configuration is a big pain, even just
> > putting a line in .emacs is a challenge ("Where is this file?", "How can
> > it have just an extension and no name?", "Why is the extension longer
> > than three letters", etc.)
>
> I think I may have suggested this the last time, but is some sort of
> bootable live CD / live USB key an option? Our livecd-creator tool is
> especially flexible: you could build a live CD / key which has all the
> right packages installed and all the configuration files in the right
> place and starts up the editor of your choice when they log in.
>
> http://www-128.ibm.com/developerworks/linux/library/l-fedora-livecd/index.h
>tml http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo
>
> Persistence (of files in the project) is a problem but maybe they can
> be encouraged to save project files to a network share or on to a USB
> key.
>
> Rich.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFI3PZpfIRcEFL/JewRAppxAJ9nDJZQzbl8jj5cyNeXup/OP/E5/ACfS88c
+VOTtD2kfFZQ7Lnna+GzOyw=
=mOfZ
-----END PGP SIGNATURE-----
Dario Teixeira
Your problem is simplified by the fact you already have dual
boot machines (if not, Richard's live CD idea is always a good
option). Unix is Ocaml's natural habitat, and some of the
problems you mentioned (like symlinks for Ocamlbuild) would
simply go away if you boot into Ubuntu.
I got the impression your students are not too familiar with
Unix. Well, if that's the case I think in the long term they
can only benefit by being exposed to it. I once had to teach
3rd year Compsci students the fundamentals of Unix programming
in C. Much to my surprise, some of them didn't even know how
to use basic shell commands or to invoke gcc! I guess my
predecessors had sheltered them too much from the "big bad
Unix".
Now, I understand you may be reluctant to spend valuable class
time teaching them the rudiments of Unix, but I reckon that if
you provide them with the relevant configuration files they can
be up and running in less than half an hour. And I bet that
some of them may even discover that they prefer Unix.
Cheers,
Dario
Arthur Chan
Make sure your OCaml has prerequisites that involve some shittier language
like C, which is taught in a Unix environment with xemacs. Once the
students have seen how awful it can get and they associate the terrible
learning experience with C (what's with the lack of love for emacs anyway?
=/), then you come to the rescue. :-D
Btw, I wouldn't try to use OCaml with Ubuntu, or *any* recent language that
has been in development. Support is generally flaky. The mainline OCaml
that comes with Ubuntu is fine, but the gl+gtk support is broken. The
version of Eclipse that ships with Ubuntu is freaking ancient and won't
support the Scala plugin. From what I remember, 8.0.4 also shipped with
some fossilized version of Scala itself.
On Fri, Sep 26, 2008 at 6:33 AM, Andrej Bauer <Andrej...@fmf.uni-lj.si>wrote:
> Hugo Ferreira wrote:
>
>> To make things simpler you may:
>> 0. Use ocamlbuild projects only.
>> 1. Prepare ocamlbuild files (tags and myocamlbuild) if necessary.
>> 2. Provide a workspace with an example project ready for compilation.
>> 3. Let the students use only one project with various source files.
>>
>
> Yes, we do all of this, but unfortunately ocamlbuild under Windows sucks
> because the trick with symbolic links to executables does not work. Has this
> been fixed yet? (Also, ocamlbuild assumes bash is in the path, also under
> Windows.)
>
> Best regards,
>
> Andrej
Richard Jones
> Make sure your OCaml has prerequisites that involve some shittier language
> like C, which is taught in a Unix environment with xemacs. Once the
> students have seen how awful it can get and they associate the terrible
> learning experience with C (what's with the lack of love for emacs anyway?
> =/), then you come to the rescue. :-D
For extra points, make sure they have to ensure that every error is
checked and every error path out of the function must free up all
resources that have been allocated ...
> Btw, I wouldn't try to use OCaml with Ubuntu, or *any* recent language that
> has been in development. Support is generally flaky. The mainline OCaml
> that comes with Ubuntu is fine, but the gl+gtk support is broken. The
> version of Eclipse that ships with Ubuntu is freaking ancient and won't
> support the Scala plugin. From what I remember, 8.0.4 also shipped with
> some fossilized version of Scala itself.
[I'm going to diss Ubuntu here ... you know where I'm coming from]
Ubuntu's OCaml support is very flaky. They don't have developers
committed to it and take a random snapshot of what's in Debian. This
has in the past led to serious brokenness where they've taken a
snaphot in the middle of a rebuild-the-world compiler upgrade.
Instead go with Debian (or Fedora) where there are developers making
sure you get a consistent, working OCaml.
Rich.
--
Richard Jones
Red Hat
_______________________________________________
Andrej Bauer
> I think we should think outside the box here.
Yes, this really is "outside the box": you suggest I should not use
Ubuntu+Eclipse to teach ocaml because it does not support Scala, and you
tell me I should teach C before I teach ocaml just so that people see
how bad C is. Definitely outside the box ;-)
I only need pure ocaml, no graphics, no gui, no OS, no threads, just
happy little language implementations (see http://andrej.com/plzoo/).
Richard Jones
> By the way, Live CD is not really an option. I suspect the computer lab
> computers are "protected" against that.
If you've got qemu installed in Ubuntu then:
qemu -m 512 -cdrom livecd.iso -boot d
You don't even need to be root. (Of course, if they have to type this
at a command prompt, arguably you've lost the battle.)
Rich.
--
Richard Jones
Red Hat
_______________________________________________
Peng Zang
Hash: SHA1
On Friday 26 September 2008 12:17:29 pm Andrej Bauer wrote:
> As far as I see, there are two options:
>
> 1) Windows + Eclipse + OcaIDE
>
> 2) Linux.
>
> The students know next to nothing about Unix. If I dive into using
> Linux, then I might as well setup anonymous subversion access to source
> code. They could use gedit for editing (it has ocaml syntax hilight
> mode), and the shell for ocamlbuild. The only unresolved question is how
> to deal with compilation errors.
I want to say use Emacs here. You can configure it behave like gedit if you
really want. Buut, I get the impression you're not willing to consider Emacs
for whatever reason. So, if gedit has a programmatic interface you can write
shell script to parse the compilation errors (just look for line numbers) and
send a command to gedit to go to the appropriate line. I don't know if gedit
has that capability, but certainly there may be other text editors that do.
> The generation that I am getting is very small (maybe 10 students), so
> this might be doable with such a small number.
>
> I will think about it. Thanks for your suggestions.
>
> By the way, Live CD is not really an option. I suspect the computer lab
> computers are "protected" against that.
That's too bad. But definitely find out, the Live CD option is great. Next
to zero work for a perfect setup.
Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFI3RVTfIRcEFL/JewRAiS3AJ40U434A7p5GWczwxWdVf4G6yL2BACghHy5
0JiT/8s1jrbeYK8YC2zJhsc=
=tGZI
-----END PGP SIGNATURE-----
Stefano Zacchiroli
> has been in development. Support is generally flaky. The mainline OCaml
> that comes with Ubuntu is fine, but the gl+gtk support is broken. The
FWIW, OCaml support in Debian is on the other hand quite good (or at
least that's what our users let us maintainers perceive), hence in
theory one can imaging using Ubuntu with legacy Debian OCaml packages.
I believe that out of the box that could be tricky to achieve if one has
already enabled Ubuntu universe (as there is no guarantee that the
versions in Debian will be considered by apt higher than those in
Ubuntu). Still, with pinning one can prioritize OCaml packages coming
from Debian.
Actually, if anyone find a good setup for that, it is worth a FAQ entry
somewhere (it will diminish the number of Ubuntu users complaining for
bad OCaml support).
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic -- Manoj \/ right keys at the right time
Jeff Shaw
cross-platform.
http://camelia.sourceforge.net/
Yaron Minsky
oriented DrScheme environment. I think they've been using it at Brown for
a year or two now, to good effect. I think Shriram Krishnamurthi is the guy
at Brown who ran the class, so you should ask him.
I agree that getting a good pedagogical IDE for OCaml is an important goal.
We'd love to fund a summer project working towards that goal. I suspect
DrOCaml is the best step in that direction so far.
y
On Fri, Sep 26, 2008 at 8:41 AM, Andrej Bauer <Andrej...@fmf.uni-lj.si>wrote:
> How can there be no easy to use interface?! This is pathetic.
>
> Python has IDLE. Scheme has drscheme. Java has drjava. What does Haskell
> have?
>
> I compiled Camelia (which required me to debug C++ code for the first time
> in about 20 years). It's kind of ok. The user interface is a bit broken,
> lots of uneccessary pop-up dialogs (e.g., for every error message).
Hugo Ferreira
> On Fri, Sep 26, 2008 at 09:15:14AM -0700, Arthur Chan wrote:
>> Btw, I wouldn't try to use OCaml with Ubuntu, or *any* recent language that
>> has been in development. Support is generally flaky. The mainline OCaml
>> that comes with Ubuntu is fine, but the gl+gtk support is broken. The
>
> FWIW, OCaml support in Debian is on the other hand quite good (or at
> least that's what our users let us maintainers perceive), hence in
> theory one can imaging using Ubuntu with legacy Debian OCaml packages.
Why not Ubuntu + GODI?
Regards,
Hugo F.
Andrej Bauer
> Have you considered DrOCaml?
Yes, but I am unable to find it. Where is it?
Hezekiah M. Carty
> Yaron Minsky wrote:
>> Have you considered DrOCaml?
>
> Yes, but I am unable to find it. Where is it?
http://planet.plt-scheme.org/display.ss?package=drocaml.plt&owner=abromfie
It works well on my system (64bit Ubuntu, OCaml 3.10.2 from GODI) but
only with DrScheme 3xx. Using DrScheme 4.x I get a series of errors:
http://planet.plt-scheme.org/trac/ticket/86
Hez
--
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science
David Teller
* Ubuntu + GODI
* Emacs + Emacs-goodies (slightly customised to obtain tabs, I can send
you my .emacs) + Tuareg -- (Emacs is much better than XEmacs, at least
for this -- and the tabs are a tremendous help)
* OcamlBuild with a myocamlbuild.ml written by you.
Cheers,
David
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings liquidations.
David Teller
was not quite compatible with my needs, though, so I dropped it.
Cheers,
David
On Fri, 2008-09-26 at 14:41 +0200, Andrej Bauer wrote:
> How can there be no easy to use interface?! This is pathetic.
>
> Python has IDLE. Scheme has drscheme. Java has drjava. What does Haskell
> have?
>
> I compiled Camelia (which required me to debug C++ code for the first
> time in about 20 years). It's kind of ok. The user interface is a bit
> broken, lots of uneccessary pop-up dialogs (e.g., for every error message).
>
> Andrej
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act
brings liquidations.
_______________________________________________
Nathaniel Gray
<Andrej...@fmf.uni-lj.si> wrote:
> Once again I am teaching a course on theory of programming languages in
> which we will use ocaml to implement mini-languages. And once again I face
> the question: which programming environment should we use?
I used to use nedit + shell and it worked quite well. I've got a good
syntax highlighting mode and some support scripts. These days I've
switched to jEdit but I use much the same workflow. It *is* possible
to use the "console" and "error list" plugins for jedit to build
programs and get automatic error message highlighting, but the OCaml
error format makes it a bit sub-optimal. If you want to try it I can
tell you how to configure things. You would still need to run the
toplevel in an external shell.
The nice thing about jEdit is that it's cross-platform and not quite
as bloated as Eclipse.
Also, using omake for your build system has some nice advantages. The
'-P' flag causes the project to automatically rebuild when any project
file changes on disk. After you fix a bug the next error message is
already waiting for you.
Cheers,
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
Erik de Castro Lopo
> Btw, I wouldn't try to use OCaml with Ubuntu,
I find the Ocaml support on Ubuntu to be excellent. This is mainly
due to the hard word of the Debian Ocaml maintainers.
> Support is generally flaky.
Sorry, thats not my experience.
> The mainline OCaml that comes with Ubuntu is fine, but the gl+gtk
> support is broken.
Use both lablgl and lablgtk (but not together) without problems.
What exactly is broken. Have you logged a bug with Ubuntu or with
the Debian Ocaml maintainers.
> version of Eclipse that ships with Ubuntu is freaking ancient and won't
> support the Scala plugin. From what I remember, 8.0.4 also shipped with
> some fossilized version of Scala itself.
I don't use Scala or Eclipse so I can't comment on that.
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"If you need a piece of paper and a pen to explain it,
then its not bleedin' obvious" -- Erik's First Law
Nathaniel Gray
> I use, on a daily basis, a small script which acts as a front-end to `make'
> and automatically points you to the error in the code in nedit, highlighting
> the characters that the ocaml compiler complains about. It uses the
> existing nedit window if you have the file open already, or else opens it
> for you. The script also works with gcc instead of ocaml, and (though I
> can't vouch for it much) gvim instead of nedit. So my typical development
> environment consists of nedit and a shell in which I compile via the script.
>
> If anyone is interested, I'd be happy to share this.
I for one am interested -- that could come in handy!
> I guess the main question would be integrating the toplevel with nedit. I
> imagine there are a number of ways to do this, depending on your needs. You
> might be able to put something together using nedit's scripting language, or
> just do something entirely external to the editor.
You won't have any luck integrating the toplevel into nedit. There's
just no way to do it within the editor as it stands today. But it's
not *that* hard to run a shell alongside your editor.
Cheers,
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
_______________________________________________
Erik de Castro Lopo
> Ubuntu's OCaml support is very flaky.
Sorry, this is not true.
In my day job we have an embedded device which is currently built
on top of Ubuntu Dapper and which we're in the process of moving to
Ubuntu Hardy.
With Dapper there was one flaky package, libcairo-ocaml-dev for
which we pulled the source package from Ubuntu Edgy and compiled
for Dapper.
Our Dapper and Hardy systems then have about a dozen utilities,
tools and daemons written in Ocaml. This experience has been a
complete joy. My manager who started as an Ocaml sceptic is a lot
less sceptical now.
> They don't have developers
> committed to it and take a random snapshot of what's in Debian.
A huge amount of kudos to the Debian Ocaml Maintainers. They
do an fantastic job. However, you are seriously overstating
any problems Ubuntu may have at least with regard to the LTS
(long term support) releases.
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Cunnilinugus and psychiatry brought us to this."
-- Tony Soprano in HBO's "the Sopranos"
Erik de Castro Lopo
> FWIW, OCaml support in Debian is on the other hand quite good (or at
Stefano, its not just good it is truely excellent.
> Actually, if anyone find a good setup for that, it is worth a FAQ entry
> somewhere (it will diminish the number of Ubuntu users complaining for
> bad OCaml support).
I am one of those Ubuntu Ocaml users and I'm not complaining.
If anyone has any a complaint about Ocaml on Ubuntu Hardy (the current
long term support release) please let them speak up. I for one would
be happy to help.
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Indeed, I am impressed that Google runs an 8,000 node Linux
cluster, 5 data centers, an extensive network, and a rapidly
evolving application all with a staff of 12."
-- http://research.microsoft.com/~gray/papers/FAAMs_HPTS.doc
Vu Ngoc San
without problems.
San
> Use both lablgl and lablgtk (but not together) without problems.
>
_______________________________________________
Stefano Zacchiroli
> What exactly is broken. Have you logged a bug with Ubuntu or with
I don't know as I don't use Ubuntu myself, but being a regular of the
Debian OCaml mailing list, it has happened multiple times (maybe 4 or 5,
I don't remember) that Ubuntu users complained about "inconsistent
assumption" errors on that list.
I don't know which was the Ubuntu release and of course I trust your
words when you say that with LTS everything is OK. I was just observing
that if in some other Ubuntu releases there are issues with OCaml stuff,
maybe they can be fixed with some pinning magics.
More generally, I've already stated in the past that we (Debian side)
are more than open towards Ubuntu developers willing to collaborate with
us for better support of OCaml in any Debian-based distro and to share
the workload (which is getting higher, as OCaml is approaching total
world domination). Sadly, nobody stepped forward to help.
If you, or anybody else, is an Ubuntu user willing to help in OCaml
package maintenance let me know, there is for sure a task for you :-)
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic -- Manoj \/ right keys at the right time
_______________________________________________
Erik de Castro Lopo
> I don't know which was the Ubuntu release and of course I trust your
> words when you say that with LTS everything is OK. I was just observing
> that if in some other Ubuntu releases there are issues with OCaml stuff,
At work we only use the LTS releases, but on my laptop I switch to
every new Ubuntu release in the early beta stages.
I have had issues with with other software in some releases. My
favourite text editor was horribly broken in Gutsy and Edgy Eft
had so many problems I only stayed with it for a week.
> More generally, I've already stated in the past that we (Debian side)
> are more than open towards Ubuntu developers willing to collaborate with
> us for better support of OCaml in any Debian-based distro and to share
> the workload (which is getting higher, as OCaml is approaching total
> world domination). Sadly, nobody stepped forward to help.
Well I'm not an official Ubuntu developer, just someone who develops
on Ubuntu, but I have joined the Debian Ocaml Maintainers mailing list
and I'm even thinking of becoming an official Debian maintainer.
> If you, or anybody else, is an Ubuntu user willing to help in OCaml
> package maintenance let me know, there is for sure a task for you :-)
Sure. Whats up?
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Men who use terrorism as a means to power, rule by terror
once they are in power."
-- Helen Macinnes
Erik de Castro Lopo
> At work we only use the LTS releases, but on my laptop I switch to
> every new Ubuntu release in the early beta stages.
>
> I have had issues with with other software in some releases. My
> favourite text editor was horribly broken in Gutsy and Edgy Eft
> had so many problems I only stayed with it for a week.
I also meant to say that apart from libcairo-ocaml-dev I've never
had a problem with the Ocaml related development environment on
the non-LTS releases either.
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"One of our programming maxims is "make illegal states unrepresentable"
by which we mean that if a given collection of values constitute an
error, then it is better to arrange for that collection of values to be
impossible to represent within the constraints of the type system."
-- Yaron Minsky
http://www.haskell.org/sitewiki/images/0/03/TMR-Issue7.pdf
David MENTRE
Context: I'm a long time Debian user, still using Debian on my
servers. But I switched my desktop machine under Ubuntu a few years ago,
seduced by the good polish and freshness of Ubuntu desktop applications.
Richard Jones <ri...@annexia.org> writes:
> Ubuntu's OCaml support is very flaky. They don't have developers
> committed to it and take a random snapshot of what's in Debian. This
> has in the past led to serious brokenness where they've taken a
> snaphot in the middle of a rebuild-the-world compiler upgrade.
I'm sorry to agree that Richard is right.
For example, I discovered at a time that *all* bytecodes shipped in Ubuntu
Gutsy could not be executed. This was fixed once spotted:
https://bugs.launchpad.net/ubuntu/+source/ocamlnet/+bug/180364
Another example: current Hardy release (which has Long Term Support
status) is shipped which OCaml 3.10.0 which is broken regarding Camlp4.
To fix this situation, one only needs people on the Ubuntu side to
synchronize packets from Debian at the right time.
As I have an direct interest in this story and while I have no knowledge
at all regarding Ubuntu workflow, I'll try to see what can be done.
Sincerely yours,
david
--
GPG/PGP key: A3AD7A2A David MENTRE <dme...@linux-france.org>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
Erik de Castro Lopo
> For example, I discovered at a time that *all* bytecodes shipped in Ubuntu
> Gutsy could not be executed. This was fixed once spotted:
> https://bugs.launchpad.net/ubuntu/+source/ocamlnet/+bug/180364
>
> Another example: current Hardy release (which has Long Term Support
> status) is shipped which OCaml 3.10.0 which is broken regarding Camlp4.
I rarely use bytecode and and have never used Camlp4 so I haven't
been hit by these, but yes, I agree, these are serious issues.
> To fix this situation, one only needs people on the Ubuntu side to
> synchronize packets from Debian at the right time.
Agree++.
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"There is no satisfactory substitute for excellence."
-- Dr. Arnold O. Beckman
Stefano Zacchiroli
> > More generally, I've already stated in the past that we (Debian side)
> > are more than open towards Ubuntu developers willing to collaborate with
> > us for better support of OCaml in any Debian-based distro and to share
> > the workload (which is getting higher, as OCaml is approaching total
> > world domination). Sadly, nobody stepped forward to help.
>
> Well I'm not an official Ubuntu developer, just someone who develops
> on Ubuntu, but I have joined the Debian Ocaml Maintainers mailing list
> and I'm even thinking of becoming an official Debian maintainer.
That's great, and thanks for your help! However, it was not only what I
meant. Surely we, Debian-side, have a lot of work to be done and help is
always needed. Still, we need someone Ubuntu-side which coordinate with
us for their releases.
We are doing an excellent job in sharing patches with Fedora (thanks
mainly to Richard of course), it's kind of astonishing that we cannot
coordinate with Ubuntu. The main reason is of course that there is
currently no "Ubuntu OCaml Maintainers" group or something similar,
would you like to start organizing one?
> > If you, or anybody else, is an Ubuntu user willing to help in OCaml
> > package maintenance let me know, there is for sure a task for you :-)
> Sure. Whats up?
You can start looking up all the bug reports against packages maintained
by debian-oc...@lists.debian.org, or other individual maintainers
of OCaml-related packages. Moreover, we have several pieces of great
OCaml softwares which are not packages while they should. We also have
some infrastructure pieces missing, if you are following the mailing
list I'm sure you are aware of some of them.
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic -- Manoj \/ right keys at the right time
_______________________________________________
Stefano Zacchiroli
> To fix this situation, one only needs people on the Ubuntu side to
> synchronize packets from Debian at the right time.
This is enough only if you assume that Ubuntu people just want to
"inherit" the Debian work. Sure this will be an improvement over the
current situation, but I frankly want more.
> As I have an direct interest in this story and while I have no knowledge
> at all regarding Ubuntu workflow, I'll try to see what can be done.
The needed steps IMO are:
0) identify who among the Ubuntu developers (core developers or MOTU, I
don't care) is willing to maintain OCaml-related stuff
1) decide upon a collaboration infrastructure and use it for *both*
Debian and Ubuntu
My proposal on this is of course to reuse Debian's, as we already have
a version control system and a mailing list, and we have already
reached a critical mass. By experience, other mixed Debian/Ubuntu
maintenance teams are using the Debian infrastructure and is working
quite well for all of the involved people
2) coordinate releases, so that the OCaml toolchain is in shape when
either of the distribution makes a release
3) total world domination
AFAIK we are still missing step 0.
--
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic -- Manoj \/ right keys at the right time
_______________________________________________
David MENTRE
Stefano Zacchiroli <za...@upsilon.cc> writes:
> 0) identify who among the Ubuntu developers (core developers or MOTU, I
> don't care) is willing to maintain OCaml-related stuff
I'm not an Ubuntu developper but I've taken on that job, at least partially:
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-September/005719.html
> 1) decide upon a collaboration infrastructure and use it for *both*
> Debian and Ubuntu
>
> My proposal on this is of course to reuse Debian's,
Great! You're answering a question I was going to ask. :-)
I'll try to submit pacthes in the following weeks.
> 2) coordinate releases, so that the OCaml toolchain is in shape when
> either of the distribution makes a release
Yep. Probably not an easy job but we can at least try.
> 3) total world domination
Work in progress, please wait... ;)
Yours,
d.
--
GPG/PGP key: A3AD7A2A David MENTRE <dme...@linux-france.org>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
_______________________________________________
Brighten Godfrey
> So, if gedit has a programmatic interface you can write
> shell script to parse the compilation errors (just look for line
> numbers) and
> send a command to gedit to go to the appropriate line. I don't
> know if gedit
> has that capability, but certainly there may be other text editors
> that do.
such as nedit -- see script below.
On Sep 26, 2008, at 3:09 PM, Nathaniel Gray wrote:
> On Fri, Sep 26, 2008 at 5:10 AM, Brighten Godfrey
> <p...@cs.berkeley.edu> wrote:
>> I use, on a daily basis, a small script which acts as a front-end
>> to `make'
>> and automatically points you to the error in the code in nedit,
>> highlighting
>> the characters that the ocaml compiler complains about. It uses the
>> existing nedit window if you have the file open already, or else
>> opens it
>> for you. The script also works with gcc instead of ocaml, and
>> (though I
>> can't vouch for it much) gvim instead of nedit. So my typical
>> development
>> environment consists of nedit and a shell in which I compile via
>> the script.
>>
>> If anyone is interested, I'd be happy to share this.
>
> I for one am interested -- that could come in handy!
OK, here it is:
http://www.cs.berkeley.edu/~pbg/mindy/
~Brighten
Kuba Ober
> How can there be no easy to use interface?! This is pathetic.
>
> Python has IDLE. Scheme has drscheme. Java has drjava. What does Haskell
> have?
If IDLE is an IDE, then I'm Santa Claus ;)
Cheers, Kuba
Kuba Ober
> which we will use ocaml to implement mini-languages. And once again I
> face the question: which programming environment should we use?
>
> 1. cygwin + ocaml + XEmacs
> 2. Eclipse + OcaIDE
>
> The second solution worked better than the first, for the simple reason
> that XEmacs is a complete mystery to students. They really, really hate
> it. But even with the second soltion we had a lot of trouble, because
> Eclipse is really complicated, and OcaIDE is sort of experimental and
> not so good under Windows, so the whole setup was confusing and fragile.
>
> The requirements are very simple:
> 1. easy access to toplevel (with line-editing)
> 2. editor which can send stuff to toplevel, points to errors in source
> code, and is not Emacs.
I've been reading through this thread and it all seems like a 300-liner
in Qt/C++ (yes, it's that powerful) (excluding syntax definition for Qt's
editor widget, if one doesn't exist somewhere for grabs).
Is there a non-Cygwin (mingw?) version of Ocaml for Windows that's "good
enough" for you? If so, I will tackle it over the weekend. My numerical
methods prof was looking for something like that too. Just give me
a pointer to a non-Cygwin version of Ocaml that works for you; I refuse
to deal with anything that has "Cygwin" in it :)
Andrej Bauer
>> The requirements are very simple: 1. easy access to toplevel (with
>> line-editing) 2. editor which can send stuff to toplevel, points to
>> errors in source code, and is not Emacs.
>
> I've been reading through this thread and it all seems like a
> 300-liner in Qt/C++ (yes, it's that powerful) (excluding syntax
> definition for Qt's editor widget, if one doesn't exist somewhere for
> grabs).
I should have added a 0-th requirement:
0. easy to install on Windows.
This means that anything which requires more than clicking on setup.exe
and following some instructions is out of the question (which is why,
for example, drocaml is out of question).
> Is there a non-Cygwin (mingw?) version of Ocaml for Windows that's
> "good enough" for you? If so, I will tackle it over the weekend. My
> numerical methods prof was looking for something like that too. Just
> give me a pointer to a non-Cygwin version of Ocaml that works for
> you; I refuse to deal with anything that has "Cygwin" in it :)
It appear that you really are Santa Claus, as you are offering presents.
By the way:
> On Friday 26 September 2008, Andrej Bauer wrote:
>> > How can there be no easy to use interface?! This is pathetic.
>> >
>> > Python has IDLE. Scheme has drscheme. Java has drjava. What does Haskell
>> > have?
>
> If IDLE is an IDE, then I'm Santa Claus ;)
So where exactly did I claim it was an IDE? I just said "easy to use
interface". Yup, definitely Santa Claus.
Best regards,
Andrej
Kuba Ober
> Kuba Ober wrote:
> >> The requirements are very simple: 1. easy access to toplevel (with
> >> line-editing) 2. editor which can send stuff to toplevel, points to
> >> errors in source code, and is not Emacs.
> >
> > I've been reading through this thread and it all seems like a
> > 300-liner in Qt/C++ (yes, it's that powerful) (excluding syntax
> > definition for Qt's editor widget, if one doesn't exist somewhere for
> > grabs).
>
> I should have added a 0-th requirement:
>
> 0. easy to install on Windows.
>
> This means that anything which requires more than clicking on setup.exe
> and following some instructions is out of the question (which is why,
> for example, drocaml is out of question).
I don't think I want to get involved in wrapping Ocaml's installation, but
all you'd need is to run two installers: Ocaml's, followed by the IDE's.
Due to the way Ocaml works under Windows, it seems that the only option
you have is to use the bytecode, as compiled code requires either an
implementation of MASM and a linker, or Cygwin (or rather, fixes to mingw
so that it can do what Cygwin does for Ocaml).
> >> > Python has IDLE. Scheme has drscheme. Java has drjava. What does
> >> > Haskell have?
> >
> > If IDLE is an IDE, then I'm Santa Claus ;)
>
> So where exactly did I claim it was an IDE? I just said "easy to use
> interface". Yup, definitely Santa Claus.
;)
OK, I'm off to work on tonight and tomorrow. My minimal goals are:
1. Editor with at least skeleton syntax highligting
2. Output window so that you can see results of your program running
3. Toplevel window so that you can run interactive sessions.
The toplevel initially won't have "readline" support, as I have to
code it from scratch, but since it's all clickable and selectable, it
should be a good first approximation to readline.
I'm still thinking how to organize the windows: should there be tabs and
an SDI-like interface? Here's how I'll do it initially:
1. One window, with a menu and a tabbed area.
2. On startup, there's a tab for toplevel.
3. If you edit a file and choose to run it, the output tab will appear,
showing the output. If there are errors, they will be highlighted
in the source. I have to check how easy it is to capture errors from
Windows version of Ocaml, and whether there should be a separate
Error sub-window under the tabbed area.
I also need to think about how to support the debugger, even though I admit
I have never used Ocaml's debugger. This would be for another weekend, though.
The goal is to have something where you can edit your sources and run them,
with errors being handled "intuitively enough".
The thing will be written in C++, as getting the necessary Ocaml bindings
generated for Qt would take too much time initially. Maybe later I'd port
it to Ocaml, as long as I can get the bindings to work well on Windows.
In the long run I'd need to patch mingw as appropriate so that Ocaml could use
it without subjecting people to Cygwin, and so that the whole thing could
be actually easily built once you install Ocaml, Mingw and Qt's sources.
Mingw toolchain needs relatively few files to run, and is rather trivial to
set up (just copy a bunch of files into a directory, and set up the path).
Cheers, Kuba
Kuba Ober
> OK, I'm off to work on tonight and tomorrow. My minimal goals are:
> 1. Editor with at least skeleton syntax highligting
> 2. Output window so that you can see results of your program running
> 3. Toplevel window so that you can run interactive sessions.
[...]
> The thing will be written in C++, as getting the necessary Ocaml bindings
> generated for Qt would take too much time initially. Maybe later I'd port
> it to Ocaml, as long as I can get the bindings to work well on Windows.
> In the long run I'd need to patch mingw as appropriate so that Ocaml could
> use it without subjecting people to Cygwin, and so that the whole thing
> could be actually easily built once you install Ocaml, Mingw and Qt's
> sources. Mingw toolchain needs relatively few files to run, and is rather
> trivial to set up (just copy a bunch of files into a directory, and set up
> the path).
Hmm, replying to myself: Camelia already does a lot of this, but I don't know
how well it works with native (non-Cygwin) OCaml. I will try it out, it seems
to be a great starting point, and it may actually get me to tweak things out
so that OCaml can do its thing without any Cygwin support at all.
My revised goals are thus:
1. Get Camelia compiled using VS/Qt4. See how it works with native
(mingw-compiled) Ocaml, tweak as necessary. Make an installer. This
is the path of least resistance, as VS is my primary development
environment.
2. Addressing some usability issues. Refactor/port to Qt4 only
as there's no GPL'd Qt3 for Windows. This means drop any Qt3
support code, and refactor the code to use Qt4 features - this
should reduce source size somewhat.
3. Install mingw compilers and compile Qt so that there's a free
platform for compiling Camelia.
4. Try compiling Camelia using those, tweak as necessary, rebuild
the installer to provide Camelia with GPL'd Qt.
5. See if it's possible to get OCaml to build natively using mingw,
without Cygwin present. Likely patch mingw to provide @responsefile
and whatever other functionality OCaml depends on.
Andrej Bauer
big favor! Thanks.
For teaching purposes the bytecode version of Ocaml should suffice.
Best regards,
Andrej
Kuba Ober
> If you can get Camelia to work properly with Qt4 you will do us all a
> big favor! Thanks.
>
> For teaching purposes the bytecode version of Ocaml should suffice.
I'm ~50% through rather mechanical refactoring/porting of the code.
This means that once I'm done with that and it compiles,
there should be about twice that much work left in actually getting
it working again (or so I hope). I have no up-front expectations
as to how well QProcess will play with non-Cygwin builds, and also
with Cygwin builds too. I plan to support native (VS/mingw) and Cygwin
OCaml builds.
I'm compiling it "cleanly" -- this means no Qt3 support.
Cheers, Kuba