- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Xtreams port to Squeak - second wave

by Levente Uzonyi

On Mon, 11 Oct 2010, Nicolas Cellier wrote: > 2010/10/11 Levente Uzonyi <leves(a)elte.hu>: >> On Sun, 10 Oct 2010, mkobetic(a)gmail.com wrote: >> >>> Hi Nicolas, >>> >>> "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> Hi again, >>>> I now have ported two more packages >>>> - Xtreams-Transforms >>>> - Xtreams-Substreams >>>> and their tests >>> >>> This is great! I loaded your code into Pharo 1.1 and things seem to be >>> working quite well. There was a complaint about missing SharedQueue2, I just >>> created a dummy subclass of SharedQueue with that name and things seemed to >>> load fine. >>> XTRecyclingCenter seems to be subclass of XTWriteStream, it should be >>> Object subclass, maybe a typo ? >>> >>>> I did not have any portability problem with those... >>>> But that's because I did not handle the Character encoder/decoder. >>>> Consequently, I have 8 tests failing (the Base64 related tests) >>> >>> I was thinking, we could implement just 'encoding: #ascii' quite easily, >>> to make this reasonably usable at least for applications that are fine with >>> that. We're actually contemplating about implementing our own encoders for >>> Xtreams too. The VW ones are tied to the classic streams more than we like. >>> You might have noticed some rather hairy parts in the encoding streams >>> yourself, where we're trying to work around some of the issues it creates. >>> The advantage of reusing the existing encoders was that there are quite a >>> few of those available, so reimplementing all that would be a drag. But we >>> can come up with a scheme where we can reimplement at least the common ones >>> and in VW we can still preserve hooking into the old ones for the rest. I >>> can give that a try on VW side in the meantime so you could get those for >>> free. >>> >>>> Plus 4 other tests failing because of my poor implementation of >>>> #after:do: (forking processes in a SUnit TestCase can't be that >>>> obvious). >>> >>> I looked at this, and I think this is how #after:do: should look like: >>> >>> after: aDelay do: aBlock >>> Â Â Â Â "Evaluate the argument block delayed after the specified duration." >>> >>> Â Â Â Â | watchdog | >>> Â Â Â Â watchdog := [ >>> Â Â Â Â Â Â Â Â aDelay wait. >>> Â Â Â Â Â Â Â Â aBlock value. >>> Â Â Â Â ] newProcess. >>> Â Â Â Â watchdog priority: Processor userInterruptPriority. >>> Â Â Â Â watchdog resume. >>> >>> This would assume that the 2 tests calling #timeout:server:client: would >>> use a Delay instance instead of a Duration, which I'd be fine with. However >>> making that change doesn't quite get the tests running. It's blowing up with >>> a DNU on the 'output close' bit in #terminate:server:client: with output >>> being nil, which I'm having trouble figuring out. I can't find who could >>> possibly be nilling it out. I'm somewhat struggling finding my way around >>> the Pharo tools. The test seems to otherwise pass but the DNUs from the >>> background process isn't nice. Also when I just click on the test in the >>> TestRunner, I actually get four DNUs, not just one as I would expect. So I'm >>> kinda stuck, not sure how to move forward without help from someone who >>> knows his way around Pharo. >>> I also get odd failure from #testWriteCollectingMultipleBufferSize, which >>> seems to run fine (against collection) when I run the equivalent in a >>> workspace, but strangely fails when running via the #timeout:server:client: >>> construct, i.e. when client and server run in separate processes. Hm, now >>> that I think of it, they sure could fail if something preempts the client, >>> server processes at the right moment. I'll have to rethink that again. >> >> These problems should be solved with the latest version of CoreTests. >> >> Levente > > Thanks! I just realized that sometimes the 100 ms timeout is not enough even on Cog and the test fails, 200 ms works well. It typically happens when running #testReadWriteLargeAmount. I'd suggest increasing it to 1000 ms or more, to make sure it doesn't fail with SqueakVM or on slower machines. Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

Re: [Pharo-project] Xtreams port to Squeak - second wave

by Nicolas Cellier

2010/10/11 Levente Uzonyi <leves(a)elte.hu>: > On Sun, 10 Oct 2010, mkobetic(a)gmail.com wrote: > >> Hi Nicolas, >> >> "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> Hi again, >>> I now have ported two more packages >>> - Xtreams-Transforms >>> - Xtreams-Substreams >>> and their tests >> >> This is great! I loaded your code into Pharo 1.1 and things seem to be >> working quite well. There was a complaint about missing SharedQueue2, I just >> created a dummy subclass of SharedQueue with that name and things seemed to >> load fine. >> XTRecyclingCenter seems to be subclass of XTWriteStream, it should be >> Object subclass, maybe a typo ? >> >>> I did not have any portability problem with those... >>> But that's because I did not handle the Character encoder/decoder. >>> Consequently, I have 8 tests failing (the Base64 related tests) >> >> I was thinking, we could implement just 'encoding: #ascii' quite easily, >> to make this reasonably usable at least for applications that are fine with >> that. We're actually contemplating about implementing our own encoders for >> Xtreams too. The VW ones are tied to the classic streams more than we like. >> You might have noticed some rather hairy parts in the encoding streams >> yourself, where we're trying to work around some of the issues it creates. >> The advantage of reusing the existing encoders was that there are quite a >> few of those available, so reimplementing all that would be a drag. But we >> can come up with a scheme where we can reimplement at least the common ones >> and in VW we can still preserve hooking into the old ones for the rest. I >> can give that a try on VW side in the meantime so you could get those for >> free. >> >>> Plus 4 other tests failing because of my poor implementation of >>> #after:do: (forking processes in a SUnit TestCase can't be that >>> obvious). >> >> I looked at this, and I think this is how #after:do: should look like: >> >> after: aDelay do: aBlock >> Â Â Â Â "Evaluate the argument block delayed after the specified duration." >> >> Â Â Â Â | watchdog | >> Â Â Â Â watchdog := [ >> Â Â Â Â Â Â Â Â aDelay wait. >> Â Â Â Â Â Â Â Â aBlock value. >> Â Â Â Â ] newProcess. >> Â Â Â Â watchdog priority: Processor userInterruptPriority. >> Â Â Â Â watchdog resume. >> >> This would assume that the 2 tests calling #timeout:server:client: would >> use a Delay instance instead of a Duration, which I'd be fine with. However >> making that change doesn't quite get the tests running. It's blowing up with >> a DNU on the 'output close' bit in #terminate:server:client: with output >> being nil, which I'm having trouble figuring out. I can't find who could >> possibly be nilling it out. I'm somewhat struggling finding my way around >> the Pharo tools. The test seems to otherwise pass but the DNUs from the >> background process isn't nice. Also when I just click on the test in the >> TestRunner, I actually get four DNUs, not just one as I would expect. So I'm >> kinda stuck, not sure how to move forward without help from someone who >> knows his way around Pharo. >> I also get odd failure from #testWriteCollectingMultipleBufferSize, which >> seems to run fine (against collection) when I run the equivalent in a >> workspace, but strangely fails when running via the #timeout:server:client: >> construct, i.e. when client and server run in separate processes. Hm, now >> that I think of it, they sure could fail if something preempts the client, >> server processes at the right moment. I'll have to rethink that again. > > These problems should be solved with the latest version of CoreTests. > > Levente Thanks!

Oct. 11, 2010

[Pharo-project] Squeak/Pharo port of Xtreams moved

by Nicolas Cellier

After Julian demand, I moved Squeak/Pharo port of Xtreams to http://www.squeaksource.com/Xtreams.html Sorry for the inconvenience, but it's better to do it now. Please update your links. Nicolas

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 21:07, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > As a friend here: when did I say I'd remove all? Â Remove and process one at a time. Â I will admit to having a bias toward doing this with a single executor per object, but even if multiples turn out to have value (need to hunt down and read Levente's description of that), the same idea should apply. > Removing and processing one at a time could do the job, but it will be very inefficient (especially on VMs which not support new finalization). Because: - you have to enter critical section for scanning valueDictionary - you then have to leave critical section for sending a single #finalize - then you should start over and look for next element with nil key (if any) So, as i said, devil in details. > Bill > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Xtreams port to Squeak - second wave

by mkobetic＠gmail.com

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. > > I have been trying some of the examples from the doc pages (google code project), this simple one still fails: > > ((1 to: 10) reading collecting: [:x | x * x]) rest Ah, that's because of the use of #cull: like semantics with exception handlers in some places, mostly ... on: Incomplete do: #count. We can certainly replace all those with regular block style. > The readline example is using the non-existing #slicer: method, this simpler version seems to work: > > |text| > text := 'line1\line2\line3\line4' withCRs reading. > text := text ender: [ :char | char = Character cr ]. > text collect: [ :line | line rest ]. > > That is a documentation bug though. Hm, odd, this is fixed in the package comments, but looks like I failed to regenerate the project pages properly. I'll review the comments again and update the site. Thanks!

Oct. 11, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by Levente Uzonyi

On Mon, 11 Oct 2010, Lukas Renggli wrote: > It is not the mailing list that is the problem, it is the > squeaksource.com server that is. It takes several minutes to calculate > a simple diff of a single version and that just kills responsiveness > at the current rate of commits. That seems to be a really high number. I just compared a version of the CollectionTests package in Squeak 4.2 with a Pharo version. The two are totally different, there are 2002 changes. Parsing both packages and creating the diffs takes less than a second with Cog. So it's probably less than 3 seconds with the standard VM. And this is an edge case. Levente > > Lukas > > On 11 October 2010 18:01, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> Maybe on a separate mailing list. >> >> Cheers, >> Alexandre >> >> >> On 11 Oct 2010, at 12:49, StÃ©phane Ducasse wrote: >> >>> I would really like to have the same behavior than the squeak system ie having the source modification >>> send to the list. I could not see how to set it up on Â squeaksource. >>> May be this is not the same version running. >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Sig, As a friend here: when did I say I'd remove all? Remove and process one at a time. I will admit to having a bias toward doing this with a single executor per object, but even if multiples turn out to have value (need to hunt down and read Levente's description of that), the same idea should apply. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 1:39 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 20:04, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Understood, but are they all that different? The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Just something to consider. > Devil is always in details. The problem can be illustrated by following: | todoList | todoList := collection select: [ some criteria ]. collection removeAllFoundIn: todoList. todoList do: [ :each | each doSomething ]. now, if inside of #doSomething you got an error, a loop is interrupted, and if you restart the process, your todoList temp is gone, since it is local to particular context, which will be discarded. You also can't restore todoList by rescanning a collection, since you removed all elements, which met your criteria. > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 1:02 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. >> > > If it would be only about restarting, then its a piece of cake. > We should make sure that all finalizations detected prior to error, > did not get lost and are able to proceed as if nothing happens, > except a single one, which failed with error. > >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Monday, October 11, 2010 12:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list >> Subject: Re: [Pharo-project] Another finalization concern: error handling >> >> Meanwhile, i'll try to implement two test cases for WeakRegistryTest. >> >> One, should cover following: >> >> coll := OrderedCollection new. >> obj := Object new. >> wrapper := WeakArray with: obj. >> coll add: wrapper. >> >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> >> obj := nil. >> Smalltalk garbageCollect. >> >> i.e somehow, user should be notified that there is an error during finalization. >> >> And second test case is to make sure that if one finalizer unable to >> complete due to error, >> the other ones (and finalization process itself) should continue >> running, skipping over errorneous finalizer. >> >> -- >> 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. > > _______________________________________________ > 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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 20:04, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Understood, but are they all that different? Â The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Â Just something to consider. > Devil is always in details. The problem can be illustrated by following: | todoList | todoList := collection select: [ some criteria ]. collection removeAllFoundIn: todoList. todoList do: [ :each | each doSomething ]. now, if inside of #doSomething you got an error, a loop is interrupted, and if you restart the process, your todoList temp is gone, since it is local to particular context, which will be discarded. You also can't restore todoList by rescanning a collection, since you removed all elements, which met your criteria. > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 1:02 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. Â That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. >> > > If it would be only about restarting, then its a piece of cake. > We should make sure that all finalizations detected prior to error, > did not get lost and are able to proceed as if nothing happens, > except a single one, which failed with error. > >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Monday, October 11, 2010 12:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list >> Subject: Re: [Pharo-project] Another finalization concern: error handling >> >> Meanwhile, i'll try to implement two test cases for WeakRegistryTest. >> >> One, should cover following: >> >> coll := OrderedCollection new. >> obj := Object new. >> wrapper := WeakArray with: obj. >> coll add: wrapper. >> >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> >> obj := nil. >> Smalltalk garbageCollect. >> >> i.e somehow, user should be notified that there is an error during finalization. >> >> And second test case is to make sure that if one finalizer unable to >> complete due to error, >> the other ones (and finalization process itself) should continue >> running, skipping over errorneous finalizer. >> >> -- >> 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. > > _______________________________________________ > 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.

Oct. 11, 2010

[Pharo-project] R: R: R: R: Problem with inspector

by morod

IÂm sorry but something may be wrong. My Pharo.image NewInspector installed System settings I tried again and the result has not changed Thanks again for your patience Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: lunedÃ¬ 11 ottobre 2010 00:23 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: R: Problem with inspector It's really strange. It works perfectly here. Step by step: - Download the last image of Pharo - Go to Monticello and load the last package of NewInspector - Go to System > Settings > Debugging > NewInspector - Check the options - Open a new inspector on an object The new children must appear. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/10 morod <morod(a)tiscali.it> Thanks for your interest, I have done what was suggested, but nothing has changed. Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: domenica 10 ottobre 2010 17:00 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: Problem with inspector If you load the last version of NewInspector (posted this morning), you go to the Settings Browser (System > Settings in the World menu), expand "Debugging" > "NewInspector" and check the options you want. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/10 morod <morod(a)tiscali.it> Hello, How can I switch from the two different versions of tool ÂInspectorÂ Best regards Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: sabato 9 ottobre 2010 14:08 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: Problem with inspector Hello, It's the NewInspector on both pictures but two different versions of this tool. In the old version, the class and the methods were displayed for each inspected object. In the current version, there are not displayed (because the community prefers less children for each object). FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/8 morod <morod(a)tiscali.it> Hi Mariano I tried it with multiple images and the behavior is the same with all the images. Sent the sample is made with: Pharo-1.1-11411 Latest update: #11411 The first one is my image and the second is taken from the book ÂPharo by ExampleÂ Thanks again Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Mariano Martinez Peck Inviato: venerdÃ¬ 8 ottobre 2010 21:43 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] Problem with inspector Hi morod, and welcome to Pharo! Which Pharo image are you exactly using? (the name of the zip, the image file or go to System -> About) The first one is your image, right ? and the second one? where is it from ? The difference is that the first image is using the "old" traditional inspector, while the second picture is using another inspector, which is called "NewInspector", which provides more information. Cheers Mariano 2010/10/8 morod <morod(a)tiscali.it> Hi iÂm new to smalltalk and Pharo and my inspector show Errore. Il nome file non Ã¨ specificato. instead of Errore. Il nome file non Ã¨ specificato. Why? Thanks _______________________________________________ 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 _______________________________________________ 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

Oct. 11, 2010

[Pharo-project] License question

by Schwab,Wilhelm K

Stef, Let's go forward in time. NativeBoost, Alien or FFI provide callbacks, I do some adaptation on my end, and out comes a pretty capable wrapper for the GNU Scientific Library. That sentence trivializes a LOT of work :( Details aside, is the wrapper code itself affected by GPL, or is it merely something unrelated that happens to invoke GSL if the latter is present on a system? What implications would that have for putting the wrapper in the inbox? This won't happen next week or next month, but depending on how easy it is to get going with callbacks, it shouldn't be years either. Bill

Oct. 11, 2010