Re: [Caml-list] Some comments on recent discussions
On 15/12/2011, Martin DeMello martindeme...@gmail.com wrote: On Wed, Dec 14, 2011 at 4:52 AM, Gerd Stolpmann i...@gerd-stolpmann.de wrote: There could be an alternative: The busybox approach. We could develop a toolkit that covers all the Unix commands we need for the existing build scripts. It would include easy things like cp, mv etc., but also a classic make (medium difficulty, note that it could reuse the godi_make code), and especially a POSIX shell. The latter is a bit of work, but not too much. I'd guess the overall effort takes not more than 1-2 weeks if done by somebody how knows the semantics of the tools very well. does mingw+msys not already do this? the last time i checked, it shipped with rxvt, bash and bunch of natively compiled standard posix utilities. It doesn't ship with much actually. sh.exe and a few things but it doesn't even have coreutils by default iirc. The usual way to setup an environment was to download every component from sourceforge.net, one by one and by trial and error until you had everything. Nowadays you can use mingw-get to download packages more easily. It's endorsed (and created) by mingw.org. It doesn't support uninstallation though and I find that many things on mingw.org are of dubious quality. That being said, msys causes problems of its own. It's a bit between Cygwin and Windows, with Cygwin already being between Windows and Unix. You quite often end up with bastard mixes between unix and windows (mostly paths: I once ended up writing a backward slash as I think). You typically don't know where you are with msys: it really blurs the line between the unix/posix and the windows worlds. Also, note that msys works like cygwin: you have a number of msys applications which use some DLL. Unlike cygwin however, you're strongly advised not ever remotely try to make your application an msys one. Btw, msys has to be built with a gcc-2.9[56] fork since it uses a target that has never been upstreamed. It's smaller than cygwin but it's not really prettier unfortunately. Regards, Adrien Nader -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Some comments on recent discussions
On 14/12/2011, David Allsopp dra-n...@metastack.com wrote:
Gerd Stolpmann wrote:
Am Mittwoch, den 14.12.2011, 09:27 -0800 schrieb Aleksey Nogin:
On 14.12.2011 04:52, Gerd Stolpmann wrote:
I don't think you will be able to convince everybody - at this point
the issue becomes political in some sense: Do we want to give up our
Unix habits just to support an OS we (often enough) do not like, and
would only cover to get more love from the world?
There could be an alternative: The busybox approach. We could
develop a toolkit that covers all the Unix commands we need for the
existing build scripts. It would include easy things like cp, mv
etc., but also a classic make (medium difficulty, note that it
could reuse the godi_make code), and especially a POSIX shell. The
latter is a bit of work, but not too much. I'd guess the overall
effort takes not more than
1-2 weeks if done by somebody how knows the semantics of the tools
very well.
There are a number of advantages over Cygwin:
- No danger of running into licensing problems
- The Unix compatibility is only maintained for commands, but not on
the system call level (eaiser to use, less surprises, fewer
deps,...)
- It would only be a small download, and easy to integrate into
installers
Note that to a degree, OMake already provides the ability to do
Unix-style things under Windows.
I know, and this makes me quite optimistic that it is not that hard to
develop standalone executables for the frequently used Unix utilities.
Any particular reason why the GnuWin32 project doesn't already fulfil this
requirement (http://gnuwin32.sourceforge.net/)?
It's not maintained well and it's often quite dirty.
This is from the main page, News section:
7 June 2009: LibPng-1.2.37: library and tools for PNG images: new release
I'm stealing the following from slackware's changelog, starting mid-2010:
Upgraded to libpng-1.2.44 and libpng-1.4.3.
This fixes out-of-bounds memory write bugs that could lead to crashes
or the execution of arbitrary code, and a memory leak bug which could
lead to application crashes.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1205
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2249
Upgraded to libpng-1.2.46 and libpng-1.4.8.
Fixed uninitialized memory read in png_format_buffer()
(Bug report by Frank Busse, related to CVE-2004-0421).
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0421
As you can see, gnuwin32's libpng is more than outdated.
Maybe we could reuse it and provide our own updated packages?
Unfortunately, the foundations are quite bad since they rely on libgw32c:
http://gnuwin32.sourceforge.net/packages/libgw32c.htm
If you look at this page, you'll see that it provides a fork() function!
Except that the body of the function is as follows:
int __fork () {
__set_errno (ENOSYS);
return -1;
}
This is a typical example and many functions are not available. Think about
it: making Windows a UNIX. That's not a trivial task and the only complete
solution is cygwin. You can't have both a unix and no additional dependency
(cygwin or interix/sua). And you don't want to do that anyway because
Windows is not UNIX: typical issues are paths and their encoding:
http://permalink.gmane.org/gmane.comp.windows.gnu.user/1197
(I'm being told that Windows paths are not UTF-16 but UCB; I'm unable to
explain more unfortunately)
Hopefully, you don't need to make applications and libraries believe they're
on a unix: most of the time, there is a windows port. For some things like
build systems (makefiles, autotools, or perl-based ones or...), it's more
difficult but you can quite simply cross-compile.
GnuWin32 and libgw32c are not completely worthless however: they can be used
for small systems (to bootstrap something bigger for instance).
Regards,
Adrien Nader
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] Some comments on recent discussions
Am Mittwoch, den 14.12.2011, 19:41 + schrieb David Allsopp: Gerd Stolpmann wrote: Am Mittwoch, den 14.12.2011, 09:27 -0800 schrieb Aleksey Nogin: On 14.12.2011 04:52, Gerd Stolpmann wrote: I don't think you will be able to convince everybody - at this point the issue becomes political in some sense: Do we want to give up our Unix habits just to support an OS we (often enough) do not like, and would only cover to get more love from the world? There could be an alternative: The busybox approach. We could develop a toolkit that covers all the Unix commands we need for the existing build scripts. It would include easy things like cp, mv etc., but also a classic make (medium difficulty, note that it could reuse the godi_make code), and especially a POSIX shell. The latter is a bit of work, but not too much. I'd guess the overall effort takes not more than 1-2 weeks if done by somebody how knows the semantics of the tools very well. There are a number of advantages over Cygwin: - No danger of running into licensing problems - The Unix compatibility is only maintained for commands, but not on the system call level (eaiser to use, less surprises, fewer deps,...) - It would only be a small download, and easy to integrate into installers Note that to a degree, OMake already provides the ability to do Unix-style things under Windows. I know, and this makes me quite optimistic that it is not that hard to develop standalone executables for the frequently used Unix utilities. Any particular reason why the GnuWin32 project doesn't already fulfil this requirement (http://gnuwin32.sourceforge.net/)? Interesting collection, but it misses a shell. Also, I'm unsure about several details. In particular, how the command-line arguments are passed down to the started process. The win32 idea of command-line is a big mess, and you will continuously run into problems if you just keep it. Cygwin works around by providing an alternate path for passing the command-line down to the started process. I fear we also would need such a mechanism. (The GnuWin32 docs do not explain completely what they do, but it reads as if they just keep the win32 conventions.) Because of this, I'm still favoring a clean reimplementation, at least of sh, make, and the frequently used file utilities. GnuWin32 might be an interesting fallback source for complicated commands where we can live with limitations (e.g. awk, which also sometimes appears in build scripts, but would be a tremendous amount of work to reproduce). Gerd -- Gerd Stolpmann, Darmstadt, Germanyg...@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details:http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Some comments on recent discussions
On Thu, Dec 15, 2011 at 2:29 AM, Adrien camarade...@gmail.com wrote: On 14/12/2011, David Allsopp dra-n...@metastack.com wrote: Any particular reason why the GnuWin32 project doesn't already fulfil this requirement (http://gnuwin32.sourceforge.net/)? It's not maintained well and it's often quite dirty. This seems better-maintained: https://github.com/bmatzelle/gow/wiki At the very least it would be a good starting point. martin -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Don't forget the user
On Wed, Dec 14, 2011 at 11:29 PM, Andrej Bauer andrej.ba...@andrej.com wrote: Recent discussions on how to improve the Ocaml-on-windows situation are very welcome, but I see a lot of tech-speak and little feeling for the users, who care just about one thing: to have a click install distribution of Ocaml that actually works. Keep this in mind: 90% of potential Ocaml users are on Windows, and they never heard of Mingw or Cygwin, and they never used a command prompt. It doesn't matter if the distribution is incomplete. It doesn't matter what is under the hood. There's another use case for a good OCaml-on-windows - people who want to write once and deploy everywhere. For that, it matters very much if the distribution is incomplete. I agree that a nice, beginner-friendly package would be a plus, though, ideally combined with a lightweight ide that is preconfigured to find the compiler in the same place that the installer puts it. martin -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml maintenance status / community fork
On Tue, 6 Dec 2011 12:31:07 +0100 Gerd Stolpmann i...@gerd-stolpmann.de wrote: I would like to comment on a tangential aspect of the rationale you gave: Given that OCaml is such a nice language with a lot of useful frameworks available, it is too sad to see it loosing ground just because of it's closed development process and lack of time of the official team. I'm quite reluctant to discuss topics about the said decline of something. However, there is certainly a point here. I have my own theory - basically the users with FP knowledge have now more options (e.g. F# or the JVM-based FP languages like Scala), and so the share for Ocaml is decreasing. This has nothing to do with the language. It's not an issue for OCaml development, it's an issue for newcomers. The main issue is : OCaml community do not have a fucking clue of what a codeflow really *is*. Never ever seen a commit only list on all of the OCaml projects seen so far. Never ever seen a patches flow working (via BTS or mail). Never read a well documented commit comment. Never read a comment on a patch or a commit. And you want hackers to be implicate in the OCaml development process with not even a working and documented codeflow, the first and essential brick any FOSS project just all share ? Cheers. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D signature.asc Description: PGP signature
Re: [Caml-list] Some comments on recent discussions
On 15/12/2011, Martin DeMello martindeme...@gmail.com wrote: On Thu, Dec 15, 2011 at 2:29 AM, Adrien camarade...@gmail.com wrote: On 14/12/2011, David Allsopp dra-n...@metastack.com wrote: Any particular reason why the GnuWin32 project doesn't already fulfil this requirement (http://gnuwin32.sourceforge.net/)? It's not maintained well and it's often quite dirty. This seems better-maintained: https://github.com/bmatzelle/gow/wiki At the very least it would be a good starting point. I had never heard of that one before and asked people about it. It turns out it's a collection of binaries already available in other places. That makes it both uninteresting and interesting. It's annoying because it will have all the bugs the other have. It's good because it saves work and you don't have to go hunt for various binaries everywhere: you have them in a single place. I think these are definitely fine for programs. Shell scripting shouldn't be an issue. Libraries of projects like gnuwin32 are probably not as good however. It shouldn't be an issue to bundle the programs if needed. :-) Regards, Adrien Nader -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Some comments on recent discussions
On Thu, Dec 15, 2011 at 12:47 PM, Adrien camarade...@gmail.com wrote: On 15/12/2011, Martin DeMello martindeme...@gmail.com wrote: This seems better-maintained: https://github.com/bmatzelle/gow/wiki At the very least it would be a good starting point. I had never heard of that one before and asked people about it. It turns out it's a collection of binaries already available in other places. That makes it both uninteresting and interesting. It's annoying because it will have all the bugs the other have. It's good because it saves work and you don't have to go hunt for various binaries everywhere: you have them in a single place. I think these are definitely fine for programs. Shell scripting shouldn't be an issue. Libraries of projects like gnuwin32 are probably not as good however. It shouldn't be an issue to bundle the programs if needed. :-) My mistake, I had the impression from the README that they were maintaining and compiling all those utilities themselves. Also, looking more closely at it, they use bash 2.03, so they clearly aren't trying to keep current. martin -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Some comments on recent discussions
On 14/12/2011, Alain Frisch al...@frisch.fr wrote: On 12/14/2011 04:49 PM, Adrien wrote: But windows actually has symlinks. Kind of. Starting with Vista and the corresponding NTFS version. But by default you need to be an administrator to use them, you can only create a limited number of symlink in a given folder afaiu, some functions work on the symlink and some on the target (stat()/lstat()). They have a number of limitations and last time I looked at them, I found them to be mostly unusable because of their limitations. They're one quite big issue I've had for packages on windows: if I cross-compile a library from Linux, and make a tarball which has a number of symlink in it. What to do when untarring on windows? Try to create symlinks? Use hardlinks when possible? Copy the file's contents? Something else? Even if Windows supports kinds of symlink internally, this is a rarely used/exposed features. I think it's a bad idea to rely on them for a packaging system (targeted to native Windows users). They would look foreign to users, and we should expect a lot of bad support from existing tools. After some discussion and pondering, I think that symlinks won't be stored as-is in the package but will instead be created during some sort of post-install hook (yypkg doesn't work that way but you get the idea). Then, if the OS or FS doesn't handle symlinks in an acceptable way, I think the following fallbacks could be used: 1- if symlink's target is a file in the symlink's folder: use a hardlink 2- if symlink's target is a file in another folder: cp the file 3- if symlink's target is a folder: try to use symlinks 4- if symlink's target is a folder and 3- is impossible, cp -r the folder 3- is based on the optimistic but realistic assumption that there aren't many symlinks to folders in a given folder, therefore avoiding the limit of 31 symlinks in a given folder on windows. I've used the following commands to find how many symlinks to directories I had in a given folder (hope it's right) (on a full slackware): find -P / -mount -type l -xtype d | xargs -L 1 -x dirname | sort | uniq -c | sort -n I got: /usr/man: 11, /etc: 9, /usr/doc/gimp-2.6.11: 8, /usr/include: 7, /usr/X11R6: 7, /media: 7, /usr/lib64/X11: 6, /usr/lib64: 6, ..., /usr/doc: 5, /usr/ 5... That shows the option 3- is quite likely to succeed. Also, note that slackware adds some symlinks to do things the way it wants (it predates Linux' standard fs hierachy ;-) ). I'd be interested in any comments. Thanks. Regards, Adrien Nader -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] REMINDER: Ireland International Conference on Education (IICE-2012): Call for Papers!
Apologies for cross-postings. Kindly email this call for papers to your colleagues, faculty members and postgraduate students. CALL FOR PAPERS ** Ireland International Conference on Education (IICE-2012), April 16-18, 2012, Dublin, Ireland (www.iicedu.org) ** The IICE is an international refereed conference dedicated to the advancement of the theory and practices in education. The IICE promotes collaborative excellence between academicians and professionals from Education. The aim of IICE is to provide an opportunity for academicians and professionals from various educational fields with cross-disciplinary interests to bridge the knowledge gap, promote research esteem and the evolution of pedagogy. The IICE 2012 invites research papers that encompass conceptual analysis, design implementation and performance evaluation. All the accepted papers will appear in the proceedings and modified version of selected papers will be published in special issues peer reviewed journals. The topics in IICE-2012 include but are not confined to the following areas: *Academic Advising and Counselling *Art Education *Adult Education *APD/Listening and Acoustics in Education Environment *Business Education *Counsellor Education *Curriculum, Research and Development *Competitive Skills *Continuing Education *Distance Education *Early Childhood Education *Educational Administration *Educational Foundations *Educational Psychology *Educational Technology *Education Policy and Leadership *Elementary Education *E-Learning *E-Manufacturing *ESL/TESL *E-Society *Geographical Education *Geographic information systems *Health Education *Higher Education *History *Home Education *Human Computer Interaction *Human Resource Development *Indigenous Education *ICT Education *Internet technologies *Imaginative Education *Kinesiology Leisure Science *K12 *Language Education *Mathematics Education *Mobile Applications *Multi-Virtual Environment *Music Education *Pedagogy *Physical Education (PE) *Reading Education *Writing Education *Religion and Education Studies *Research Assessment Exercise (RAE) *Rural Education *Science Education *Secondary Education *Second life Educators *Social Studies Education *Special Education *Student Affairs *Teacher Education *Cross-disciplinary areas of Education *Ubiquitous Computing *Virtual Reality *Wireless applications *Other Areas of Education Important Dates: *Extended Abstract (Work in Progress) Submission Date: January 15, 2012 *Research Paper, Student Paper, Case Study, Report Submission Date: January 20, 2012 *Proposal for Workshops: December 15, 2011 *Notification of Workshop Acceptance/Rejection: December 20, 2011 *Poster Proposal Submission Date: January 10, 2012 *Notification of Poster Acceptance/Rejection: January 15, 2012 *Notification of Extended Abstract (Work in Progress) Acceptance/Rejection: January 25, 2012 *Notification of Research Paper, Student Paper, Case Study, Report Acceptance /Rejection: January 30, 2012 *Camera Ready Paper Due: February 10, 2012 *Early Bird Registration Deadline (Authors and Participants): February 15, 2012 *Late Bird Registration Deadline (Authors and Participants): March 10, 2012 *Conference Dates: April 16-18, 2012 For further information please visit IICE-2012 atwww.iicedu.org -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: more ideas (Re: [Caml-list] how could the community help with Oasis-DB;) towards a CPAN for OCaml?
On Wed, Dec 14, 2011 at 04:37:26PM +0100, Gerd Stolpmann wrote: Am Mittwoch, den 14.12.2011, 15:55 +0100 schrieb oliver: On Wed, Dec 14, 2011 at 01:14:57PM +0100, Gerd Stolpmann wrote: Am Dienstag, den 13.12.2011, 21:22 +0100 schrieb oliver: Hello, I again want to mention R. The installation procdure for users is very easy. What I also like there, is that the documentation includes references to books, which explain the algorithms or other background information. Maybe thats too much of what is needed for OCaml. But it's what I do like there. Also R-packages necessarily need to be documented, have a manpage / package description. Not sure if this is necessary with OCaml stuff, because *.mli files are there, and ocamlc -i could print the interfaces of the modules, if nothing else is there to rely on. But maybe these kinds of minimalistic documentation-generation could be created automatically by the installing tools. Nicely printed html-docs for interfaces are very helpful. And also nice would be, to have such nicely printed documentation also available at the server, even before downloading any packages. So, browsing a package documentation online could be done before downloading the package. docs.camlcity.org [...] Yes, I see. There are these nice htmlized-docs. But I meant that this kind of docs also should also be on a CPAN-like server for OCaml. So every package that is available there should also be documented in this way. Yes, it's a third party server. What's the problem? [...] if it offers a shell and the possibility to install OCaml (or maybe the admin could od that), then there is no problem. ocamlc -i and caml2html can be used then to create the docs automotically. My thinking here is different: We should lower the barriers for packages as far as possible. We are not in the position of CPAN who can reject packages not conforming to a relatively high standard. People who are able to program in OCaml also might be able to add some additional simple textfiles for further informations, if necessary. Some more docs would be fine. But maybe that not even is necessary for a minmal set of docs. The creation of the interface docs can be done as mentioned above. Additionally there was a module (forgot the name, but could look for it), which also displays the hierrchy of modules (which module uses which other modules). All this could be deon automatically, if the server at least offers a shell and OCaml. Unpacking an archive, applying ocamlc and caml2html could be done automatically. And if one looks at CTAN, there are some additional simple text files (package descriptions) which help organizing this. I think overengineering is not a good idea, but a minimal helping text file should be possible for people who claim to program in OCaml. For example there was/is the Linux Software Map; it's already forgotten by most people, but once was a very useful tool... it doies exist today, but maybe not very frequently used. But there it was a simple text file with some informations about the software, that was added and had a very simple format. It was parsed automatically and created the data dfor the search catalog. Thats btw. a lot less effort than clikcing around in so many menues in the modern web driven software hosting possibilities. I think it should be possible to add such a simple textfile. If that is too much for OCaml programmrs, I doubt that any person ever will want to use the software that will be hosted there. I think there are enough very knowledgable people hacking in OCaml. So this little barrier should be able to cross. docs.camlcity.org does the best in this situation: If there is a manual, you can look at this. But if not, there is at least a pretty-printed interface, and you can search these interfaces. That's what I meant. Is this doc generated automatically? That's what I was looking for. And the module-hierarchy of a program could also be added. But the people who upload their stuff should be encouraged to add documentation. Maybe some tools could help there. I like it that C-extensions to R necessarily need a documentation file. I would not insist on such a thing for OCaml, but if you look at what the result is, when looking at R-package documentation, this is convincing. It uses - like classical unix manpages - certain topics, which will be checked if they are used. If OCaml stands for quality, why not insisting at least on a minimal kind of documentation? Ciao, Oliver -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
