- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.0] #10510

by Marcus Denker

10510 ----- Issue 1788: SMTPClient does not send HELO or EHLO, session is not initiated Issue 1953: Network: smtp should send helo first -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 14, 2010

Re: [Pharo-project] web services, pharo

by John M McIntosh

Well *cough* I've always wondered why we use a un-supported smalltalk based decoder here versus relying on the JPEGReadWriter2 which uses the JPEG libraries we bundle into the VMs. Maybe you should to a quick performance test and see how they compare? On 2010-02-14, at 4:01 AM, laurent laffont wrote: > Arghh it's almost done but I have a bug: > > SketchMorph fromStream: ('http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/AAAAAAAAA1A/jySYN6rz_pc/DSC00…' asUrl retrieveContents contents readStream) > > fails: image format is not recognized. > > In JPEGReadWriter class >> understandsImageFormat > aStream next = 16rFF answer false ??? > - aStream next answers a Character instance > - 16rFF is a SmallInteger > - both equals 255. > > What is the right way to correct that ? > > Laurent Laffont > > > 2010/2/13 Mariano Martinez Peck <marianopeck(a)gmail.com> > I think he talks about this one > > http://coweb.cc.gatech.edu/squeakbook/ > > > 2010/2/13 laurent laffont <laurent.laffont(a)gmail.com> > Which web page ? > > Laurent Laffont > > > > On Sat, Feb 13, 2010 at 3:42 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > laurent have a look in the network chapter of the new blue book (collective book available on web page) > because I do not remember but you could find some snippets going in the same sense. > > Stef > > On Feb 13, 2010, at 3:29 PM, laurent laffont wrote: > > > (SketchMorph fromStream: > > ('http://code.google.com/p/pharo/logo' > > asUrl retrieveContents contentStream)) openInWorld > > > _______________________________________________ > 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 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 14, 2010

Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by John M McIntosh

Adding a multi-threaded FFI interface is always feasible. What I'd suggest is some get their corporate sponsor to pay for it as part of building the Alien FFI plugin for Unix and Windows. Then gift it back to the community, otherwise you'll see zero movement. On 2010-02-14, at 4:42 AM, Mariano Martinez Peck wrote: > I have a simple question: Does someone know if AlienFFI still locks the complete VM while executing a function ? I mean, it behaves exactly as normal FFI in that aspect ? I would love a FFI that doesn't lock the VM. Or even better, let you choose, like VW FFI. > > Cheers > > Mariano > > On Sun, Feb 14, 2010 at 11:44 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > >> Yes Alien is the way to go. > > > > I wonder why you think that. Alien is > > - mac only (you may say it's not true, because one could build a unix or > > windows vm that supports it, but that didn't happen in the past 1.5 > > years) > > - x86 only > > > I'm not knowledgeable enough but I refer here to some discussions I got with > eliot when we were at amsterdam. The comments I heard on the FFI implementation > were not that positive. > > Now may be there is a road for FFI and Alien and it would be good to have the > extension lukas did in 3.9. > > Stef > > > _______________________________________________ > 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 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 14, 2010

Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by StÃ©phane Ducasse

On Feb 14, 2010, at 4:01 PM, Schwab,Wilhelm K wrote: > Stef, > > I've always understood why you launched Pharo. > > On FFI/Alien and blocking the entire VM, I injected Dolphin's overlapped calls into a discussion of the (rather serious) problems that can arise when something does not return as soon as expected (or at all), and somebody with good VM awareness (I do not recall who[*]) described a way to get around it. I recall thinking what a loss it is that good ideas often don't get packaged for general use. > > FWIW, here are my suggestions for ideas that should be given high priority: I would like to be able to do it myself but I don't know how to do it. > (1) Alien plugins for Linux and Windows; Alien as a mac-only entity is far less attractive than a cross-platform alternative. yes we should get the one of linux running since there was a fix. > (2) For FFI, we need a generic callback mechanism. It sounds as though one can be built using a plugin and some indirection. > (3) For FFI and Alien, we need something like Dolphin's overlapped calls. Hopefully a generic solution that starts a thread and waits on a semaphore can be created once, and perhaps eventually enhanced with some thread pooling options. For now, I'd take one os thread per call, or (perhaps the ideal) one os thread per Smalltalk process blocked on such a call, as I think Dolphin does now, in part due to Windows stupidities. > > I also recall a lengthy discussion about efficiency in making calls to COM objects from Dolphin, with someone arguing very hard to make calls a certain way because the alternative (while much simpler) was too slow. The flaw in that argument was that calls in question were by nature few and infrequent; the overhead of making the call was dwarfed by the work that resulted. Much of my use of FFI is similar. I am not arguing in favor of inefficient calls, but a sub-optimal but flexible way to make a callback (FFI) and to make a call on an os thread (FFI/Alien) would be much appreciated in most situations, I see > even if it takes a few extra milliseconds compared to something optimally coded if I had time and knowledge to do so. I do not make millions of external calls; I make a few that do millions of floating point operations. A little extra time to put a socket connect (thinking OpenSSL) call on a background thread is trivial next to the cost of having a direct call go into limbo and hang a server process. > > Bill > > [*] seriously, it might have been "the FFI maintainer" or somebody else. I do recall that whoever it is knows a lot more about the vm than I do. > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Sunday, February 14, 2010 4:30 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game) > > Ok thanks for the historical refresh. Some people may now understand why we finally decided to do Pharo. > Now let us stop ranting and think about the blue sky of the new horizon. > What do we do in Pharo 1.1? > :) > I'm full ears open. > > Stef > > > > >>>>> It is interesting to note that of course, after this was added to 3.9, there was >>>>> someone *very hard* arguing that adding Pragmas was a very dumb idea... >>>>> >>>>> Who that person was is left as an exercise to the reader of course ;-) >>>> >>>> Hint: FFI has its own proprietary hardcoded pragma format. It >>>> unnecessary complicates the compiler even when not loaded. Not to >>>> mention that it breaks all tools that have their own parser, such as >>>> RB for example. >>>> >>> >>> I'd like to discuss, what changes to compiler we may introduce to allow FFI >>> to handle pragmas in non-intrusive manner. >>> >> >> Very simple: FFI just needs to use the pragmas as introduces in 3.9, than remove all >> knowledge about FFI from the Compiler. Problem solved. Isn't that beautiful? >> >> < cdecl: void 'InvalRect' ( MacRect ) module: 'InterfaceLib'> >> >> of that would be changed so that the stuff inside the <> would be a standard Smalltalk Message expression, problem solved. >> >> to illustrate... using the SMaCC grammar of the NewCompiler (a bit simplified) as extendend for Pragmas, Primitives and FFI by >> Mathiue Suen. >> >> A method in Squeak has Pragmas: >> >> Method: >> | MethodPattern Temporaries Pragmas Statements {#methodTempsPragma:}; >> >> >> So they are difined like this (we can have multiple ones): >> >> Pragmas: >> "<" PragmaMessage ">" {#pragma:} >> | Pragmas "<" PragmaMessage ">" {#pragmas:} >> >> So it's quite simple: there is one message expression inside... simple. But there is FFI. Primitives are >> there, too, but that's not really a problem: they fit in the Pragmas. primitive: 15 is a valid message in Smalltalk. >> (Math did the gramar for primitives to have nice error messages, but that's not needed) >> >> PragmaMessage: >> Apicall {#messagePragma:} >> | Primitive {#messagePragma:} >> | MessagePragma {#messagePragma:}; >> >> How Primitive and MessagePragma are done is not important. But we need Gramar rules just to be able to parse >> FFI: >> >> Apicall: >> TypeCall ExternalType IndexName "(" ParameterApicall <rightParentheses> {#externalCall:} >> | TypeCall ExternalType IndexName "(" ParameterApicall <rightParentheses> "module:" <string> {#externalModuleCall:}; >> >> IndexName: >> <string> {#externalFunction:} >> | <number> {#externalIndex:}; >> >> TypeCall: >> "apicall:" {#callConvention:} >> | "cdecl:" {#callConvention:}; >> >> ParameterApicall: >> ExternalType {#parameterExtCall:} >> | ParameterApicall ExternalType {#parametersExtCall:}; >> >> ExternalType: >> <name> {#externalType:} >> | <name> "*" {#externalTypePointer:}; >> >> >> And this is *always* in the Grammar. Even when FFI is not loaded! (a nice example where our simple notion of >> modularity brakes down completely). >> >> No the solution here is simple: a small trivial modification to FFI to use the Evil Pragmas as introduced by the Dumb >> People (tm) in 3.9: >> >> < cdecl: 'void InvalRect ( MacRect )' module: 'InterfaceLib'> >> >> or *whatever*. just something that is a valid Smalltalk message expression... can't be hard, can it? >> >> Ah. And and about "notion of modularity"... of course the problem "how can I extend the language from >> my package without having to spread code over the parser, compiler, debugger, browser..." is intellectually >> an interesting one. And, oh, we are payed for finding these kind of Problems and especially solving these Problems >> in a way that goes beyond of just doing a pragmatic and simple solution (aka what I described here). >> (They call it "Academic Research". Involves mostly a programming language called TeX and can be very boring at times >> but it's complementary to the practical world... in a very interesting way). >> >> And int his context the result is, of course, tataaa....: Lukas' Helvetia: >> >> http://scg.unibe.ch/research/helvetia/languageboxes >> >> See? So *everything* fits together... research and non-research, problems and solutions (on multiple levels), >> progress in the small and the large! >> >> Marcus >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> 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

Feb. 14, 2010

Re: [Pharo-project] web services, pharo

by laurent laffont

On Sun, Feb 14, 2010 at 4:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > ;) > BTW did you convert my old videos? > yes, sort of : http://pharocasts.blogspot.com/2010/01/learn-smalltalk-with-profstef.html Laurent > > Stef > > On Feb 14, 2010, at 1:20 PM, laurent laffont wrote: > > > > > > > Make sure that the stream is binary: > > SketchMorph fromStream: (' > http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/AAAAAAAAA1A/jySYN6rz_pc/DSC00…' > asUrl retrieveContents contents asByteArray readStream) > > > > > > Levente > > > > > > It works ! Thank you ! You've just saved a screencast :) > > > > Laurent Laffont > > > > > > > > > > > > > > Laurent Laffont > > > > > > 2010/2/13 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > > I think he talks about this one > > > > http://coweb.cc.gatech.edu/squeakbook/ > > > > > > 2010/2/13 laurent laffont <laurent.laffont(a)gmail.com> > > > > Which web page ? > > > > Laurent Laffont > > > > > > > > On Sat, Feb 13, 2010 at 3:42 PM, StÃ©phane Ducasse < > > stephane.ducasse(a)inria.fr> wrote: > > > > laurent have a look in the network chapter of the new blue book > > (collective book available on web page) > > because I do not remember but you could find some snippets going in the > > same sense. > > > > Stef > > > > On Feb 13, 2010, at 3:29 PM, laurent laffont wrote: > > > > (SketchMorph fromStream: > > ('http://code.google.com/p/pharo/logo' > > asUrl retrieveContents contentStream)) openInWorld > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > > 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 >

Feb. 14, 2010

Re: [Pharo-project] web services, pharo

by StÃ©phane Ducasse

;) BTW did you convert my old videos? Stef On Feb 14, 2010, at 1:20 PM, laurent laffont wrote: > > > Make sure that the stream is binary: > SketchMorph fromStream: ('http://lh3.ggpht.com/_BvlW9mJ6MFc/R-p4PtCKitI/AAAAAAAAA1A/jySYN6rz_pc/DSC00…' asUrl retrieveContents contents asByteArray readStream) > > > Levente > > > It works ! Thank you ! You've just saved a screencast :) > > Laurent Laffont > > > > > > > Laurent Laffont > > > 2010/2/13 Mariano Martinez Peck <marianopeck(a)gmail.com> > > I think he talks about this one > > http://coweb.cc.gatech.edu/squeakbook/ > > > 2010/2/13 laurent laffont <laurent.laffont(a)gmail.com> > > Which web page ? > > Laurent Laffont > > > > On Sat, Feb 13, 2010 at 3:42 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > laurent have a look in the network chapter of the new blue book > (collective book available on web page) > because I do not remember but you could find some snippets going in the > same sense. > > Stef > > On Feb 13, 2010, at 3:29 PM, laurent laffont wrote: > > (SketchMorph fromStream: > ('http://code.google.com/p/pharo/logo' > asUrl retrieveContents contentStream)) openInWorld > > > _______________________________________________ > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 14, 2010

Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by Schwab,Wilhelm K

Stef, I've always understood why you launched Pharo. On FFI/Alien and blocking the entire VM, I injected Dolphin's overlapped calls into a discussion of the (rather serious) problems that can arise when something does not return as soon as expected (or at all), and somebody with good VM awareness (I do not recall who[*]) described a way to get around it. I recall thinking what a loss it is that good ideas often don't get packaged for general use. FWIW, here are my suggestions for ideas that should be given high priority: (1) Alien plugins for Linux and Windows; Alien as a mac-only entity is far less attractive than a cross-platform alternative. (2) For FFI, we need a generic callback mechanism. It sounds as though one can be built using a plugin and some indirection. (3) For FFI and Alien, we need something like Dolphin's overlapped calls. Hopefully a generic solution that starts a thread and waits on a semaphore can be created once, and perhaps eventually enhanced with some thread pooling options. For now, I'd take one os thread per call, or (perhaps the ideal) one os thread per Smalltalk process blocked on such a call, as I think Dolphin does now, in part due to Windows stupidities. I also recall a lengthy discussion about efficiency in making calls to COM objects from Dolphin, with someone arguing very hard to make calls a certain way because the alternative (while much simpler) was too slow. The flaw in that argument was that calls in question were by nature few and infrequent; the overhead of making the call was dwarfed by the work that resulted. Much of my use of FFI is similar. I am not arguing in favor of inefficient calls, but a sub-optimal but flexible way to make a callback (FFI) and to make a call on an os thread (FFI/Alien) would be much appreciated in most situations, even if it takes a few extra milliseconds compared to something optimally coded if I had time and knowledge to do so. I do not make millions of external calls; I make a few that do millions of floating point operations. A little extra time to put a socket connect (thinking OpenSSL) call on a background thread is trivial next to the cost of having a direct call go into limbo and hang a server process. Bill [*] seriously, it might have been "the FFI maintainer" or somebody else. I do recall that whoever it is knows a lot more about the vm than I do. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, February 14, 2010 4:30 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game) Ok thanks for the historical refresh. Some people may now understand why we finally decided to do Pharo. Now let us stop ranting and think about the blue sky of the new horizon. What do we do in Pharo 1.1? :) I'm full ears open. Stef >>>> It is interesting to note that of course, after this was added to 3.9, there was >>>> someone *very hard* arguing that adding Pragmas was a very dumb idea... >>>> >>>> Who that person was is left as an exercise to the reader of course ;-) >>> >>> Hint: FFI has its own proprietary hardcoded pragma format. It >>> unnecessary complicates the compiler even when not loaded. Not to >>> mention that it breaks all tools that have their own parser, such as >>> RB for example. >>> >> >> I'd like to discuss, what changes to compiler we may introduce to allow FFI >> to handle pragmas in non-intrusive manner. >> > > Very simple: FFI just needs to use the pragmas as introduces in 3.9, than remove all > knowledge about FFI from the Compiler. Problem solved. Isn't that beautiful? > > < cdecl: void 'InvalRect' ( MacRect ) module: 'InterfaceLib'> > > of that would be changed so that the stuff inside the <> would be a standard Smalltalk Message expression, problem solved. > > to illustrate... using the SMaCC grammar of the NewCompiler (a bit simplified) as extendend for Pragmas, Primitives and FFI by > Mathiue Suen. > > A method in Squeak has Pragmas: > > Method: > | MethodPattern Temporaries Pragmas Statements {#methodTempsPragma:}; > > > So they are difined like this (we can have multiple ones): > > Pragmas: > "<" PragmaMessage ">" {#pragma:} > | Pragmas "<" PragmaMessage ">" {#pragmas:} > > So it's quite simple: there is one message expression inside... simple. But there is FFI. Primitives are > there, too, but that's not really a problem: they fit in the Pragmas. primitive: 15 is a valid message in Smalltalk. > (Math did the gramar for primitives to have nice error messages, but that's not needed) > > PragmaMessage: > Apicall {#messagePragma:} > | Primitive {#messagePragma:} > | MessagePragma {#messagePragma:}; > > How Primitive and MessagePragma are done is not important. But we need Gramar rules just to be able to parse > FFI: > > Apicall: > TypeCall ExternalType IndexName "(" ParameterApicall <rightParentheses> {#externalCall:} > | TypeCall ExternalType IndexName "(" ParameterApicall <rightParentheses> "module:" <string> {#externalModuleCall:}; > > IndexName: > <string> {#externalFunction:} > | <number> {#externalIndex:}; > > TypeCall: > "apicall:" {#callConvention:} > | "cdecl:" {#callConvention:}; > > ParameterApicall: > ExternalType {#parameterExtCall:} > | ParameterApicall ExternalType {#parametersExtCall:}; > > ExternalType: > <name> {#externalType:} > | <name> "*" {#externalTypePointer:}; > > > And this is *always* in the Grammar. Even when FFI is not loaded! (a nice example where our simple notion of > modularity brakes down completely). > > No the solution here is simple: a small trivial modification to FFI to use the Evil Pragmas as introduced by the Dumb > People (tm) in 3.9: > > < cdecl: 'void InvalRect ( MacRect )' module: 'InterfaceLib'> > > or *whatever*. just something that is a valid Smalltalk message expression... can't be hard, can it? > > Ah. And and about "notion of modularity"... of course the problem "how can I extend the language from > my package without having to spread code over the parser, compiler, debugger, browser..." is intellectually > an interesting one. And, oh, we are payed for finding these kind of Problems and especially solving these Problems > in a way that goes beyond of just doing a pragmatic and simple solution (aka what I described here). > (They call it "Academic Research". Involves mostly a programming language called TeX and can be very boring at times > but it's complementary to the practical world... in a very interesting way). > > And int his context the result is, of course, tataaa....: Lukas' Helvetia: > > http://scg.unibe.ch/research/helvetia/languageboxes > > See? So *everything* fits together... research and non-research, problems and solutions (on multiple levels), > progress in the small and the large! > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > 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

Feb. 14, 2010

[Pharo-project] HelpSystem implementation

by Danny Chan

Hi Thorsten! I have two questions regarding your implementation: - What is the reason to have HelpBuilder and to create a hierarchy of HelpTopic instances mirroring the layout of the actual content classes? Why not use the class objects directly? - Why do you use pragmas for the titles of the pages? If I understand correctly, pragmas are for metadata of methods, but it seems to me that the title of a page belongs to its data just as much as its contents do. Danny

Feb. 14, 2010

Re: [Pharo-project] GoferApiTest failing (WinXP)

by Mariano Martinez Peck

On Sun, Feb 14, 2010 at 12:46 AM, Ch Lamprecht <ch.l.ngre(a)online.de> wrote: > Hello to everybody, > > running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see > GoferApiTest>>#testSubDirectoryRepository failing. > It could be fixed by changing > > MCSubDirectoryRepository>>#description > > + ^ directory pathName, FileDirectory slash , '*' > - ^ directory pathName, '/*' > > The current implementation works because '/' and '\' both are valid path > separators on windows. Assuming '/' as path delimiter would cause trouble > with > MacFileDirectory - but that might be obsolete anyway. > So may be the test is too strict? > > Hi Christoph. First, welcome! I hope you enjoy. It was already reported. See http://n4.nabble.com/Failing-Gofer-test-in-windows-WAS-BetaTesting-ANN-Phar… Thanks Mariano > I just started to follow this list and the Pharo project ('Recreational > programmer' btw. - thanks for the kind welcome message ;) ). Should I > report > this? And if so: It is a MC issue, should it be reported using the Pharo > tracker > or somewere else? > > Cheers, Christoph > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 14, 2010

Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by Mariano Martinez Peck

I have a simple question: Does someone know if AlienFFI still locks the complete VM while executing a function ? I mean, it behaves exactly as normal FFI in that aspect ? I would love a FFI that doesn't lock the VM. Or even better, let you choose, like VW FFI. Cheers Mariano On Sun, Feb 14, 2010 at 11:44 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > > >> Yes Alien is the way to go. > > > > I wonder why you think that. Alien is > > - mac only (you may say it's not true, because one could build a unix or > > windows vm that supports it, but that didn't happen in the past 1.5 > > years) > > - x86 only > > > I'm not knowledgeable enough but I refer here to some discussions I got > with > eliot when we were at amsterdam. The comments I heard on the FFI > implementation > were not that positive. > > Now may be there is a road for FFI and Alien and it would be good to have > the > extension lukas did in 3.9. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 14, 2010