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

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

[update 3.0] #30425

by Marcus Denker

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 Camillo Bruni

On 2013-09-26, at 12:29, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > We have FileDialogWindow, which is a cool little class which implements all > the cool things you may want to do when selecting a file, for example: > - answer either a directory, file, file entry, etc. > - set an initial directory > - set the sorting block > > Life is good. > > <rant> > Then, we take the entire domain of opening files and cram it into UITheme's > chooseXyzFileAbcIn:j:k:l: methods. UITheme is also a nice little class... > with 570 instance methods... wait, wth! Okay, but forgetting polymorph's > design for a moment... > > Then, we take the handful of options that UITheme gives us and funnel those > through UIManager, which exposes... 3. > > So out of the entire domain of selecting files, we have three safe options > available. > > This doesn't seem to work. > </rant> > > Naively, it seems to me that much of the original power could be retained if > things were reversed a bit. For example, instead of implementing file > selection functionality in three places (FileDialogWindow, UITheme, and > UIManager), could we do: > > 1. FileDialogWindow implements the API for selecting files > 2. UITheme only returns an appropriately-themed object (wth are "services" > doing in UITheme anyway?!) > 3. UIManager subclasses return either (via e.g. "UIManager default > fileDialogWindow"): > a) The themed object > or > b) a Dummy object that no-ops #1's API > > I'd be willing to give it a try if any of that sounds promising or if > someone has a better idea. Just image that the UIManager should also work on the CommandLine, everything else I couldn't agree more ;). Returning any window on UIManager is wrong I think, we should only define the request interface there. Of corse the MorphicUIManager can have its internal helper method to return the request window to lower the load on UITHeme.

Sept. 26, 2013