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

SmalltalkHub use of LESS stylesheets

by Esteban A. Maringolo

Hi all, The SmalltalkHub website seems to be using LESS stylesheets, which are downloaded in a sequential order, and it takes ~20sec to download the styles. Wouldn't it be better to compile the LESS stylesheets to regular CSS files (combined and minified in a single file would be great). LESS stylesheets are not meant to be used in production environments. I thinks that only with that the speedup will be significant. Regards, Esteban A. Maringolo

Sept. 27, 2013

Re: [Pharo-dev] UI Mess

by Camillo Bruni

On 2013-09-26, at 15:50, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > 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) I would also say that spans over the most common options. Convert #pattern: to #filter: which takes a block over the shown file reference and you can implement almost everything ;)

Sept. 26, 2013

Re: [Pharo-dev] [Issue Tracker] input of submitters/bug fixers needed

by kilon

I agree, closing bugs , or deleting them, on the grounds that none has comment on them for a very long time is a very bad idea. Pharo has a small crowd of users and I seriously doubt they care much of the bug report process. That does not make a bug any less important though. In the end of the day, it would depend upon on a dev that seriously needs that bug fixed and does it himself. But then the questions arises how many people that find themselves against a bug don't choose curtain number 2 and go around the bug instead of fixing it , since it gets the job done faster. Blender used to have close to 500 bugs ( now it has around 300 ), and it has around 30 monthly commiters with at least 600 commits per month ( https://www.ohloh.net/p/blender <https://www.ohloh.net/p/blender> ). So its not as bad as it seems. About non important bugs, very easy to fix bugs and already solved bugs, I doubt that there are as many as you wish to think :) Bugs are rarely a walk in the park , hence why bug fixing is not a favorite habit :D -- View this message in context: http://forum.world.st/Issue-Tracker-input-of-submitters-bug-fixers-needed-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 26, 2013

Re: [Pharo-dev] [Issue Tracker] input of submitters/bug fixers needed

by StÃ©phane Ducasse

On Sep 26, 2013, at 3:57 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-09-26, at 10:23, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> Marcus Denker-4 wrote >>> The problem is that if we have over 500 entries, people just give up. >>> They say "what use is it to fix 1, there are just too many". >> >> Okay, so I think a "Resolved" status like "Stale" would be a good >> compromise. Then we can close the issue, but it will be tagged as to the >> reason, so in my example I can have a filter for closed issues tagged Stale, >> and easily reopen them if necessary. The problem is that now I have to wade >> through hundreds of closed issues I worked on to find the ones that were >> closed due to inactivity - not fun. > > > we have a couple of statuses that come close to that: > Resolved Postponed indeed Postponed should be close to stale and I understand Sean concerns. > Resolved Won't Fix > > If you want we can decide upon Postponed and then close them. > Could you check that this is in sync with the status description? > > https://pharo.fogbugz.com/default.asp?W65

Sept. 26, 2013

Re: [Pharo-dev] UI Mess

by StÃ©phane Ducasse

If you remember a while ago I was thinking that the theme could be managed like settings (ie encapsulated in the widgets and that the widgets could encapsulate their default for theme), but sadly I was wrong because a theme oftn requires specific computation. So probably we should have a widget and some object that represents the theme strategy. Ideally I would like to get rid of the UIManager theme idea but this is difficult and it requires a bit of prototyping. So if one of you want to try to see on a typical case how a design could work. It would be really great. Setf

Sept. 26, 2013

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

by StÃ©phane Ducasse

Thanks we appreciate :) Bootstrap pharo, pharo consortium, and business is taking a lot of time and energy :) But we will do it. > > Yes, I know. I'm trying to close all the ones I have around at the moment before opening a new one :) > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Sept. 26, 2013

Re: [Pharo-dev] UI Mess

by Sean P. DeNigris

Goubier Thierry wrote > answer := UIManager default > chooseFileReference: 'Select a file' > path: aFileReference > pattern: '*.png' > name: nil I can't tell if that captures the full options of fileDialogWindow without a bit more investigation, but that would be a great improvement over the current mess. I feel that whatever we do should be coupled with moving the open/answer logic into that single entry point and out of UITheme. UITheme should only provide the morph. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Mess-tp4710579p4710620.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 26, 2013

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

by Erwan Douaille

https://pharo.fogbugz.com/default.asp?11690 just as a reminder :) 2013/9/26 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > 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 > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Sept. 26, 2013

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