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

Re: [Pharo-project] How to open a file with external app

by Holger Hans Peter Freyther

On Wed, Mar 27, 2013 at 11:26:21PM +0100, Camillo Bruni wrote: > The only solution currently is to use OSProcess and > - open under OSX > - gnome-open under linux Please use xdg-open to work on all free desktop implementations.

March 28, 2013

Re: [Pharo-project] in anybody out there? who uses 2.0?

by Marcus Denker

On Mar 28, 2013, at 9:39 AM, phil(a)highoctane.be wrote: > Yep, seems BlockContext is gone Yes, it is not used since Pharo 1.0â¦ it's dead code. Of course we can keep it for and build a nice Museum of dead code. Marcus

March 28, 2013

Re: [Pharo-project] in anybody out there? who uses 2.0?

by phil＠highoctane.be

Yep, seems BlockContext is gone. Ran into that as well. No idea on how to fix tough. Throwing in BlockClosure instead makes me feel like playing russian roulette. Maybe Lukas repository has updates (as for Seaside) Phil 2013/3/28 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Did anybody manage to load Magritte 2 at least? > > When running this: > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfMagritte2'; > load. > > (ConfigurationOfMagritte2 project version: '2.0.6') load: #('Magritte-Seaside') > > I get the following error: > This package depends on the following classes: > BlockContext > You must resolve these dependencies before you will be able to load > these definitions: > magritteDynamicObject > > Esteban A. Maringolo > > > 2013/3/27 Sean P. DeNigris <sean(a)clipperadams.com>: >> EstebanLM wrote >>> So... I wonder... is that because we made a really cool release, or just >>> because nobody is using it? >> >> I've ported most of my projects to 2.0, but I've been on holidays for a few >> weeks, so I haven't updated to the released version. I'll know better this >> week, but IIRC most of the bugs I noticed have been fixed. >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/in-anybody-out-there-who-uses-2-0-tp4678552p4678640.h… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >

March 28, 2013

[Pharo-project] Nautilus: Class Side vs. Instance Side

by Mircea Filip Lungu

Hi people, I've installed Pharo 2.0 to give it a try. All good until now! Looking at Nautilus I see that where there used to be two buttons for switching between class-side and instance-side methods, now there is a checkbox. As I was slowly trying to get used to it... it occurred to me that I would have liked even more if I would not have to switch at all. In fact it would be so much nicer to see everything about a class at once. One solution might be splitting the protocols panel in two for instance and class side. Just my 2C. Cheers, M. -- Dr. Mircea Lungu Researcher Software Composition Group University of Bern

March 28, 2013

Re: [Pharo-project] Non-Smalltalk content in Pharo and Nautilus

by Serge Stinckwich

Yes I agree very good idea for a GSoc, please send us a proposal. Regards EnvoyÃ© de mon iPhone Le 28 mars 2013 Ã 00:03, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> a Ã©crit : > Exactly what I was about to propose :) > Write a GSoC proposal ^^ > > Ben > > On Mar 27, 2013, at 9:29 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> >> >> On Wed, Mar 27, 2013 at 9:18 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> When working with Seaside (or other frameworks) one often works with non-Smalltalk resources >>> stored within the image (CSS styles, images, ...) often stored as strings within >>> methods: >>> >>> >>> myCss >>> ^'body { >>> background-color: #ffffce; >>> }' >>> >>> or >>> >>> script >>> ^'alert("hello from Javascript");' >>> >>> >>> I also often see Base64 encoded images, or when working with XML a method >>> might return XML content. >>> >>> With things like Helvetia [1], the reworked autocompletion/syntax highlighting and new >>> browsers like Nautilus in mind I wonder if (may be in the not so far future) I can: >>> >>> - click on a Smalltalk method to get ST styling and edit functionality >>> - click on a CSS content method to do CSS styling and completion >>> - click on a method with a form content to display the picture (and not the Base64 encoded string) >>> - click on an XML content to browse the XML tree >>> - click on an HTML providing method to edit HTML and maybe preview >>> - click on a method with CSV to edit the tabular data within a grid >>> - click on a primitive method to see Slang or C/C++ code >>> - ... >>> >>> Internally the content can be distinguished using pragmas: >>> >>> >>> myCss >>> <mime-type: text/css> >>> ^'body { >>> background-color: #ffffce; >>> }' >>> >>> >>> Are there any plans to move Pharo into this "not only Smalltalk" in methods direction? >>> >>> Is it already possible to easily extend Nautilus with "pluggable" custom panes depending on the >>> method content. >>> >>> I see that there are buttons on the Nautilus side. Wouldnt it be better to have "Tabs" >>> with "Source" as default and where I can add my own custom tabs? >>> >>> Would be a lot of work to provide editors and stylers for all the mime-types or autocompletion >>> for JavaScript, SQL, ... whatever. But the question is more "do we have the groundwork so >>> people can built up on it." >>> >>> Any comments? >> >> I'd like to see something like that... >> a GSOC? >> >>> >>> Thx >>> T. >>> >>> [1] http://scg.unibe.ch/research/helvetia >

March 28, 2013

Re: [Pharo-project] strange problem in CompiledMethod>>=

by Marcus Denker

On Mar 28, 2013, at 8:05 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 28, 2013, at 6:59 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> One of the Moose test runs a visualization that manipulates CompiledMethods, and it runs into an error when trying to find an entry inside a dictionary that has compiled methods as keys. In the end, I managed to isolate the problem that can be reproduced by: >> >> 1. Download the moose image: >> https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/arti… >> >> 2. Execute: >> (MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:). >> Hmmâ¦ I think I was completely wrong. The problem is that the methods are from a Trait and something goes wrong because of that. I think the problem is the #traitSource annotation, it seems that the code for = has problems when properties are defined on methods. Marcus

March 28, 2013

[Pharo-project] Fwd: How to open a file with external app

by Max Leske

forwarding... Begin forwarded message: > From: Philippe Back <philippe.back(a)gmail.com> > Subject: RE : Re: [Pharo-project] How to open a file with external app > Date: 28. MÃ¤rz 2013 08:07:54 MEZ > To: Max Leske <maxleske(a)gmail.com> > > There is an example in the dic/help server that uses nb to open a web browser that way (NB) > > > Philippe Back > > > > Max Leske <maxleske(a)gmail.com> a Ã©crit : > > > > On 27.03.2013, at 23:26, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > The only solution currently is to use OSProcess and > > - open under OSX > > - gnome-open under linux > > Or use NativeBoost (e.g. run C code that does what you want). But Camillo's solution is certainly easier to implement. > > > > > > > On 2013-03-27, at 23:05, jannik.laval <jannik.laval(a)gmail.com> wrote: > > > >> Hi pharoers, > >> > >> Is it possible to select a file and open it with an external application ? > >> For example, I need to open a pdf file. > >> > >> How can I do that ? > >> > >> Thank you for the help, > >> Jannik > >> > > > > > >

March 28, 2013

Re: [Pharo-project] in anybody out there? who uses 2.0?

by Marcus Denker

On Mar 28, 2013, at 4:56 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > > > I had noticed that package loading seemed extremely slow, but did not look further into it. I think I saw mention that it's due to some usage of #become:, during the compiling of code. Based on build times (of just loading the rough equivalent code), it seems about 3 times slower to do a build on a Pharo-2.0 vs. Pharo-1.4. > Yes, this is known and we should analyze itâ¦ one thing we need to get rid of os the #become: when updating the source pointer. There seems to be something slow with announcing changes, too. > > Another thing I've noticed is occasional sluggishness in the UI. It's hard to pinpoint, I often feel like my clicks are being lost. > I have not seen that one. > The behaviour of the TestRunner was odd. Eventually I discovered running tests via the Nautilus browser, but the UI feedback is extremely confusing for "abstract" test cases. I still don't quite understand the results I see there, so I do a final run of the tests in the TestRunner. > Odd in which sense? related to the progress bar? > Another strange issue I had with test cases was to do with the interaction of the deprecation warnings. In by build script, I run: > Deprecation raiseWarning: false. > Deprecation showWarning: false. > so the build can run headless. It took me a few hours, and a careful single stepping, to find that the deprecation exceptions were being swallowed. I'm sure the TestRunner did not behave this way before. If you ran a test, you would still see the deprecation exceptions. It was really frustrating to see your test fail, but have the stack cleared out before you could debug the exception that caused the test failure. > Can you add a bug tracker entry for that one? Marcus

March 28, 2013

Re: [Pharo-project] strange problem in CompiledMethod>>=

by Marcus Denker

On Mar 28, 2013, at 6:59 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > One of the Moose test runs a visualization that manipulates CompiledMethods, and it runs into an error when trying to find an entry inside a dictionary that has compiled methods as keys. In the end, I managed to isolate the problem that can be reproduced by: > > 1. Download the moose image: > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/arti… > > 2. Execute: > (MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:). > > > It seems it is a Pharo problem, or something related to these particular methods. Would anyone be interested in looking into this? > Yes, equality just check that the byte code is the same. Historically this is the behavior as methods did not know their class nor their selector, at some point they where then including this information for #=, but the latest does not. We should change it, Methods now contain the information in which class they are installed in and it should be taken into account for = There is already a case: https://pharo.fogbugz.com/f/cases/7222 Marcus

March 28, 2013

Re: [Pharo-project] strange problem in CompiledMethod>>=

by Tudor Girba

Hi, I have put together a little analysis and got to 684 problematic pairs in the Moose image: allCompiledMethods := Object withAllSubclasses flatCollect: #methods. problematicCases := OrderedCollection new. allCompiledMethods allPairsDo: [ :a :b | [a = b] on: Error do: [ problematicCases add: a->b ] ]. FileSystem disk workingDirectory / 'problematicCompiledMethodsEquality.txt' writeStreamDo: [ :stream | problematicCases associationsDo: [ :each | stream nextPutAll: '(', each key printString, ') = (', each value printString, ')'; cr ] ] It takes a while to run this, so I put the result in the attachment. There are quite a number of problematic comparisons that can be reproduced in the original Pharo image, too, so I think we found a bug. Cheers, Doru On Mar 28, 2013, at 6:59 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > One of the Moose test runs a visualization that manipulates CompiledMethods, and it runs into an error when trying to find an entry inside a dictionary that has compiled methods as keys. In the end, I managed to isolate the problem that can be reproduced by: > > 1. Download the moose image: > https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/arti… > > 2. Execute: > (MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:). > > > It seems it is a Pharo problem, or something related to these particular methods. Would anyone be interested in looking into this? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > -- www.tudorgirba.com "Don't give to get. Just give."

March 28, 2013