September 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] LGPL considered crippling license :)

by Igor Stasenko

I haven't visited the Orge site long ago, i found an interesting news, that they switching license to MIT! The motivation & conclusions why they decided to switch are very interesting: --- citation --- Wonât this mean people can ârip offâ OGRE in proprietary software? The LGPL already allowed OGRE to be used in proprietary software, and this is something weâve always encouraged. The main difference between the LGPL and the MIT License is that there is no requirement to release modified source code; only to include our copyright and the MIT license text in the final product. While not requiring modified source to be released might initially seem like giving up an important motivator to contribute code back to the community, weâve noticed something in recent years: 99% of useful code contributions come from people who are motivated to participate in the project regardless of what the license tells them they have to do. Itâs our experience that a certain percentage of the user community will always participate and contribute back, and therefore encouraging adoption via simpler licensing is likely to result in more contributions overall than coersion via complex and restrictive licensing does. In addition, people who are internally motivated to participate tend to provide much higher quality and more usable contributions than those who only do it because they are forced to. --- citation --- you can read the full article here: http://www.ogre3d.org/2009/09/15/ogre-will-switch-to-the-mit-license-from-1… P.S. i found it a very good sign, that more and more open-source communities gradually moving towards more permissive license, as MIT is. -- Best regards, Igor Stasenko AKA sig.

Sept. 26, 2009

Re: [Pharo-project] CAnalyer

by Igor Stasenko

2009/9/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > Is it something you have made available? Â One snag in my world is that the "code" is not always something that can be compiled. Â However, for GSL and other libraries of interest, the code is valid, if not full of macro-based annoyances and other distractions. > the code i written is the module to SWIG. The project what i developed once is to write a smalltalk interpreter by own, and the aim was to use it as a scripting engine for C++ projects. My experiments stopped shortly after i understood that my interpreter implementation having some flaws and i need to spend much time to rewrite everything :) But, along the way, i started making bindings to Ogre 3D engine (http://www.ogre3d.org/) and my SWIG-based binding code generator were able to reflect C++ classes in my own smalltalk, including being able to call constructors/destructors, methods and directly access the fields by using auto-generated primives. If you wanna to get deeper into that, i can send you the sources and examples. With a little effort, the code generation could be easily changed to satisfy the FFI/Alien demands, then you will be able to bind any C library with Squeak VM. > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Friday, September 25, 2009 11:03 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] CAnalyer > > 2009/9/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> I was digging around on Squeak Source for OSProcess and friends, and ran across CAnalyzer. Â Are there any papers on it? Â How robust is it? Â What does it extract from C code? Â For example, might one put the GSL (www.gnu.org/software/gsl) header files into it, pull out all of the structure definitions and function prototypes, and generate LOTS of FFI code to make a wrapper? Â Just a thought... >> > > I having a modified version of SWIG, which can parse C++ files, including classes and nested classes, to produce smalltalk code wrappers. > > Reproducing the SWIG in smalltalk would be very time consuming. > But it would be cool to have a C/C++ parser implementation. > > SWIG is not only parsing, its also doing macro preprocessing, so its can't be fooled with macros :) > >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 26, 2009

[Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel

by StÃ©phane Ducasse

Hi I kind of agree on this one. So what is the preferred solution. Now this is important to be able to distinguish an empty string from a cancel. Stef Begin forwarded message: > From: codesite-noreply(a)google.com > Date: September 26, 2009 5:07:13 AM CEDT > To: stephane.ducasse(a)gmail.com > Subject: Issue 1129 in pharo: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > > > Comment #17 on issue 1129 by andreas.raab: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > http://code.google.com/p/pharo/issues/detail?id=1129 > > Can I ask to reopen this issue before 1.0 goes out? It introduces a > superficial > incompatibility between Pharo and Squeak or other external code that > is really > unecessary. There are two excellent alternatives: > > 1) Extend the existing protocol, by means of, e.g, > result := UIMananger default request: 'What is your name?' onCancel: > ["whatever"]. > This allows for a simple and straightforward use in cases where one > needs to > distinguish between cancel and empty return and it trivially extends > to uses of > multiLineRequest: as well re requestPassword:. > > 2) Alternatively, introduce a new protocol and deprecate the old > one. For example: > result := UIManager default ask: 'What is your name?'. > With a changed protocol any breakage is straightforward and obvious > and not subtle > and in corner cases that may not be tested for by some external > code. Plus, it is > possible to provide a compatibility layer where necessary. > > From my point of view both of the above are far better solutions and > do not require > any additional work. > > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

Sept. 26, 2009

Re: [Pharo-project] [update] closure fixes :)

by StÃ©phane Ducasse

Hi guys since mike started from an older version of the image to integrate the changes, let me know if you nocticed that some changes got lost. I'm checking how I could check that automatically. Stef On Sep 25, 2009, at 10:01 PM, StÃ©phane Ducasse wrote: > > Thanks thanks thanks eliot and mike. > > Now I will check if we did not rollbacked some fixes I did and some > pending changes.... > And we should soon to ReleaseCandidate. > > Stef > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

Re: [Pharo-project] Opening image multiple times - bug or feature?

by Douglas Brebner

Igor Stasenko wrote: > 2009/9/25 Douglas Brebner <squeaklists(a)fang.demon.co.uk>: > >> John M McIntosh wrote: >> >>> Actually the WIndows VM use to lie, might still, if you opened a file >>> READ/WRITE but it was read only, like on a CD, then the windows VM would >>> say SURE no problem. This caused grief for macintosh users using one- >>> click apps on a CD because we would cause a walkback saying we >>> couldn't open the file READ/WRITE. >>> >>> >> The problem I had was code that was written on unix that opened the same >> file twice in write mode in the initialization methods. Broke nastily on >> windows with confusing exceptions and leaking file handles iirc. >> >> >> BTW, opening an image twice at the same time on windows give the >> "changes file not accessible" popup at startup of the second image. >> >> > Right, because on windows you can obtain an exclusive write-lock on a > file for a process and disallow others > to open it for writing. > AFAIK, POSIX systems also allowing locking the file handle through > using ioctl(). > > Yep, and windows isn't the only one that does this by default, it's merely the most common :)

Sept. 26, 2009

Re: [Pharo-project] Titles of tool windows are inappropriate

by StÃ©phane Ducasse

Thanks andrew On Sep 26, 2009, at 2:42 AM, Andrew P. Black wrote: > Inspectors on an object foo say "foo on NewInspector" in the title. > They should just say "foo". Workspaces say "Shout Workspace"; that's > an implementation detail. I put a changeset in the bug database to > fixes these annoyances. (Issue 1245) > > Andrew > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

Re: [Pharo-project] CAnalyer

by Schwab,Wilhelm K

Sig, Is it something you have made available? One snag in my world is that the "code" is not always something that can be compiled. However, for GSL and other libraries of interest, the code is valid, if not full of macro-based annoyances and other distractions. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, September 25, 2009 11:03 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] CAnalyer 2009/9/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > I was digging around on Squeak Source for OSProcess and friends, and ran across CAnalyzer. Â Are there any papers on it? Â How robust is it? Â What does it extract from C code? Â For example, might one put the GSL (www.gnu.org/software/gsl) header files into it, pull out all of the structure definitions and function prototypes, and generate LOTS of FFI code to make a wrapper? Â Just a thought... > I having a modified version of SWIG, which can parse C++ files, including classes and nested classes, to produce smalltalk code wrappers. Reproducing the SWIG in smalltalk would be very time consuming. But it would be cool to have a C/C++ parser implementation. SWIG is not only parsing, its also doing macro preprocessing, so its can't be fooled with macros :) > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

Re: [Pharo-project] CAnalyer

by Igor Stasenko

2009/9/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > I was digging around on Squeak Source for OSProcess and friends, and ran across CAnalyzer. Â Are there any papers on it? Â How robust is it? Â What does it extract from C code? Â For example, might one put the GSL (www.gnu.org/software/gsl) header files into it, pull out all of the structure definitions and function prototypes, and generate LOTS of FFI code to make a wrapper? Â Just a thought... > I having a modified version of SWIG, which can parse C++ files, including classes and nested classes, to produce smalltalk code wrappers. Reproducing the SWIG in smalltalk would be very time consuming. But it would be cool to have a C/C++ parser implementation. SWIG is not only parsing, its also doing macro preprocessing, so its can't be fooled with macros :) > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 26, 2009

[Pharo-project] OSProcess question

by Schwab,Wilhelm K

I see various ways to run something, none of which are quite what I want. The objective is to run openssl in a particular directory. I have no need to make this portable (unless you mean running on all of Ubuntu, Debian, Slackware, etc. <g>), so #forkAndExec:...workingDirectory: would almost be ok, **but**, I need to wait around for the result. In truth, there are a few things that have to happen in sequence; perhaps I could simply write multiple lines to the command string. Still, in the interest of idealism, it would be nice to run the commands on other than the Pharo main thread (no sense diving into something that might not return[*]), and to know when the work is done, and to get the different steps to happen in sequence. There was mention of tests for OSProcess (which might provide clues), but I have not been able to find them. Any hints? Bill [*] insert Windows joke here :)

Sept. 26, 2009

[Pharo-project] CAnalyer

by Schwab,Wilhelm K

I was digging around on Squeak Source for OSProcess and friends, and ran across CAnalyzer. Are there any papers on it? How robust is it? What does it extract from C code? For example, might one put the GSL (www.gnu.org/software/gsl) header files into it, pull out all of the structure definitions and function prototypes, and generate LOTS of FFI code to make a wrapper? Just a thought... Bill

Sept. 26, 2009