- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [PROVENANCE INTERNET] Re: A simple File browser ?

by StÃ©phane Ducasse

On Sep 26, 2013, at 11:35 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Solution: > > (UIManager default chooseFullFileName: 'Choose an Icon' extensions: nil path: nil preview: nil) asFileReference > > We could probably clean up a bit those chooseXXX methods :) oh yes! If we could get more time. Stef

Sept. 26, 2013

Re: [Pharo-dev] Strange FileDoesNotExistException when loading code from Seaside...

by Mariano Martinez Peck

mmmm it is similar to an error that appears in some Jenkins jobs like: ASTCache>>at: in Block: [31m==== Startup Error: FileDoesNotExistException: '< https://ci.inria.fr/pharo-contribution/job/Fuel/PHARO=30,VERSION=bleedingEd… '> [0mMultiByteFileStream class(StandardFileStream class)>>readOnlyFileNamed: MultiByteFileStream(StandardFileStream)>>readOnlyCopy RemoteString>>string CompiledMethod>>getSourceFromFile OpalCompiler>>decompileMethod: CompiledMethod>>decompile CompiledMethod>>decompileString CompiledMethod>>source does it sound any bell? On Thu, Sep 26, 2013 at 3:40 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Of course, executing the SAME load code from the workspace in the image > does work....so this is only when I trigger it from a seaside > button...weird... > > > On Thu, Sep 26, 2013 at 3:31 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> ups...here is the screenshot. >> >> >> On Thu, Sep 26, 2013 at 3:28 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Hi guys, >>> >>> I have a link in a Seaside app that allow us to trigger a Metacello load >>> to update the source code. It has a weird error....I get >>> a FileDoesNotExistException with the .changes file, which indeed exists. >>> The error is in #readOnlyFileNamed:. I attach an screenshot of the stack. >>> >>> What is funny is that the compiled method that has the problem is always >>> (or at least most of the times) either WAAttribute>>#accept: or >>> WAAttribute>>#isAdvanced ... >>> >>> More funny...if I open a debugger in the problem, and I re-execute >>> readOnlyFileNamed: it works! (of course, because the .changes file does >>> exists). >>> >>> Does anyone had a similar problem? >>> Thanks, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Sept. 26, 2013

Re: [Pharo-dev] [update 3.0] #30425

by Pavel Krivanek

The update build failed on Linux slave -- Pavel 2013/9/26 Marcus Denker <marcus.denker(a)inria.fr>: > 30425 > ----- > > 11687 Merge Opal with Opal Repository > https://pharo.fogbugz.com/f/cases/11687 > > 11688 Pharo Kernel shrinking update for 30424 > https://pharo.fogbugz.com/f/cases/11688 > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.9… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… >

Sept. 26, 2013

Re: [Pharo-dev] UI Mess

by GOUBIER Thierry

Thanks, Sean, I'm happy that after Erwan suggestion of an issue, someone took charge of cleaning that :) My own position is that current Pharo has unified the filesystem issue with FileReference, and that I'm not impressed by moving ten variants of an API for choosing files from one class to another. But that's just me :) I think at the core we have a single method which returns FileReferences, and which has four parameters: title, start path, pattern, name (no need for an open). I'll move some of the API complexity in the pattern object, so that it may be able to make the distinction between files and directory, and of course extensions (with a reflective method to list the possible extensions). The pattern should be easy to create :), i.e. nil, '*.png', #isADirectory, whatever. All parameters may be nil, and like that there isn't any dependency on Morphic or the command line. answer := UIManager default chooseFileReference: 'Select a file' path: aFileReference pattern: '*.png' name: nil (name: is for those Save As dialogs where you already have a pre-existing file name) Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Sean P. DeNigris [sean(a)clipperadams.com] Date d'envoi : jeudi 26 septembre 2013 20:24 Ã : pharo-dev(a)lists.pharo.org Objet : Re: [Pharo-dev] UI Mess Camillo Bruni-3 wrote > Just image that the UIManager should also work on the CommandLine After browsing UICommandLineManager>>#chooseFrom:lines:title:, I see where we are headed - mimicking the headful interactions via stdin/out. Very cool! Camillo Bruni-3 wrote > Returning any window on UIManager is wrong I think, we should only define > the > request interface there In light of the above, I agree that returning a window doesn't make sense. And, "defining the request interface" seems okay for simple requests like the one above, but for e.g. selecting from the filesystem, there are just too many options. We already have 8 such messages in UIManager and it doesn't expose all the combinations. I think in cases of this complexity, it would be better to return a helper object, so client code could write: UIManager default fileChooser title: 'Choose Xyz'; selectDirectory: myDefaultDirectory; openInWorld. "maybe a generic #open would be nicer" which would return FileDialogWindow for Morphic, or for the command line, a polymorphic object interacting via stdin/out. My main point is that FileDialogWindow already defines an API for selecting files and it's wasteful and error-prone to duplicate it in UIManager. Does that approach sound better? ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Mess-tp4710579p4710601.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 26, 2013

Re: [Pharo-dev] Strange FileDoesNotExistException when loading code from Seaside...

by Mariano Martinez Peck

Of course, executing the SAME load code from the workspace in the image does work....so this is only when I trigger it from a seaside button...weird... On Thu, Sep 26, 2013 at 3:31 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > ups...here is the screenshot. > > > On Thu, Sep 26, 2013 at 3:28 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi guys, >> >> I have a link in a Seaside app that allow us to trigger a Metacello load >> to update the source code. It has a weird error....I get >> a FileDoesNotExistException with the .changes file, which indeed exists. >> The error is in #readOnlyFileNamed:. I attach an screenshot of the stack. >> >> What is funny is that the compiled method that has the problem is always >> (or at least most of the times) either WAAttribute>>#accept: or >> WAAttribute>>#isAdvanced ... >> >> More funny...if I open a debugger in the problem, and I re-execute >> readOnlyFileNamed: it works! (of course, because the .changes file does >> exists). >> >> Does anyone had a similar problem? >> Thanks, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Sept. 26, 2013

Pharo Launcher cant launch Image on Windows

by kilon

Pharo Launcher cant launch images it download on windows . Does not understand in ExternalWindowProcess >> value , nextPutAll:. There is however a comment inside the method that says : "FIXME: Close the initial pipe handles. For now, I have not implemented passing these to the child, and there is no support yet for nonblocking Windows OS pipes. Once those are available, this method needs to change to support." Is this why image launching fails, or is it unrelated ? problem has been reported by BTC here -> https://pharo.fogbugz.com/f/cases/11616/Launching-fails-in-Windows <https://pharo.fogbugz.com/f/cases/11616/Launching-fails-in-Windows> it appears that the problem has been fixed in this -> https://pharo.fogbugz.com/f/cases/11569 <https://pharo.fogbugz.com/f/cases/11569> still I get the very same error with the latest Pharo Launcher image Can anyone confirm the problem and the error he/she get ? I am on windows only when I am at work, and I am strictly macos on home. Though it seems I will be installing windows here too via bootcamp so I can work on these issues. -- View this message in context: http://forum.world.st/Pharo-Launcher-cant-launch-Image-on-Windows-tp4710603… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 26, 2013

Re: [Pharo-dev] Strange FileDoesNotExistException when loading code from Seaside...

by Mariano Martinez Peck

ups...here is the screenshot. On Thu, Sep 26, 2013 at 3:28 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys, > > I have a link in a Seaside app that allow us to trigger a Metacello load > to update the source code. It has a weird error....I get > a FileDoesNotExistException with the .changes file, which indeed exists. > The error is in #readOnlyFileNamed:. I attach an screenshot of the stack. > > What is funny is that the compiled method that has the problem is always > (or at least most of the times) either WAAttribute>>#accept: or > WAAttribute>>#isAdvanced ... > > More funny...if I open a debugger in the problem, and I re-execute > readOnlyFileNamed: it works! (of course, because the .changes file does > exists). > > Does anyone had a similar problem? > Thanks, > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Sept. 26, 2013

Strange FileDoesNotExistException when loading code from Seaside...

by Mariano Martinez Peck

Hi guys, I have a link in a Seaside app that allow us to trigger a Metacello load to update the source code. It has a weird error....I get a FileDoesNotExistException with the .changes file, which indeed exists. The error is in #readOnlyFileNamed:. I attach an screenshot of the stack. What is funny is that the compiled method that has the problem is always (or at least most of the times) either WAAttribute>>#accept: or WAAttribute>>#isAdvanced ... More funny...if I open a debugger in the problem, and I re-execute readOnlyFileNamed: it works! (of course, because the .changes file does exists). Does anyone had a similar problem? Thanks, -- Mariano http://marianopeck.wordpress.com

Sept. 26, 2013

Re: [Pharo-dev] UI Mess

by Sean P. DeNigris

Camillo Bruni-3 wrote > Just image that the UIManager should also work on the CommandLine After browsing UICommandLineManager>>#chooseFrom:lines:title:, I see where we are headed - mimicking the headful interactions via stdin/out. Very cool! Camillo Bruni-3 wrote > Returning any window on UIManager is wrong I think, we should only define > the > request interface there In light of the above, I agree that returning a window doesn't make sense. And, "defining the request interface" seems okay for simple requests like the one above, but for e.g. selecting from the filesystem, there are just too many options. We already have 8 such messages in UIManager and it doesn't expose all the combinations. I think in cases of this complexity, it would be better to return a helper object, so client code could write: UIManager default fileChooser title: 'Choose Xyz'; selectDirectory: myDefaultDirectory; openInWorld. "maybe a generic #open would be nicer" which would return FileDialogWindow for Morphic, or for the command line, a polymorphic object interacting via stdin/out. My main point is that FileDialogWindow already defines an API for selecting files and it's wasteful and error-prone to duplicate it in UIManager. Does that approach sound better? ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Mess-tp4710579p4710601.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 26, 2013

Re: [Pharo-dev] [Pharo-users] [ANN] Launching Pharo on Ubuntu

by btc＠openinworld.com

Sept. 26, 2013