Re: [Pharo-project] Metacello configuration conventions
On 22 Apr 2013, at 17:37, Dale Henrichs wrote: > Now that folks like you are asking for features that I think I've addressed > in the Scripting API, perhaps I can start getting some meaningful feedback. > If your projects are on Pharo2.0, you'll have to wait for Christophe and I to > finish the port, otherwise you can take it for a spin[1] (there is some > documentation as well) and let me know what makes sense to you and what > doesn't. We're using the scripting api since almost a year and it seems to behave :-) Btw, I also did some work to make it run in Pharo2.0 but it's not yet working entirely. What is the location of your code changes on this so I can merge in when I get back to it? Btw, I did run into some load problems where strange conflicts got reported in gemstone... you might be getting that bug report sooner than you want ;-) Cheers Johan
[Pharo-project] the fun theory
When I saw this website, I immediately thought about Pharo http://www.thefuntheory.com "This site is dedicated to the thought that something as simple as fun is the easiest way to change people’s behaviour for the better." Keep having fun! Johan
Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness
I'm fine with the fact that Pharo decides to put that as a default (because I
can change it).
But the preferences are fundamentally flawed: if I disable useEnterToAccept
then I cannot even use instead.
I should also disable the as the completion of common prefixes.
The change I attached to my email demonstrates that this should not be the case.
On 07 Apr 2013, at 12:27, Esteban Lorenzano wrote:
> I still think useEnterToAccept has to be true
> I sustain the idea of lower the entry level for the newcomers, instead
> supporting as default the use-workflow of power users (they have a settings
> browser there).
> We took this decision last year and I think it was a good one... not that we
> cannot change, but I would stick with it for now.
>
> I think the current completion functionality has some other problems that
> makes it sometimes uncomfortable to use...
>
> On Apr 7, 2013, at 12:16 PM, stephane ducasse
> wrote:
>
>>
>> On Apr 6, 2013, at 11:44 PM, Benjamin
>> wrote:
>>
>>> If everybody likes it, maybe we should consider putting this configuration
>>> as default, no ?
>>
>> yes but first I would like to see the difference because I do not like it :)
>>
>>
>>> Ben
>>>
>>> On Apr 6, 2013, at 8:59 PM, "Sean P. DeNigris"
>>> wrote:
>>>
stephane ducasse wrote
> would it be possible to get a couple of settings that you use?
NECPreferences
enabled: true;
caseSensitive: true;
expandPrefixes: true;
useEnterToAccept: false;
smartCharacters: true;
smartCharactersWithDoubleSpace: '[]{}';
spaceAfterCompletion: false;
popupAutomaticDelay: 100.
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4679488p4679997.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>
>>
>
Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness
Indeed, I also increased the popup speed in the preferences to something like 100 or 200ms. But yes, you should wait for them to pop up. I did not address any other issues than the 'completion keystroke'. btw, judging by the time of day, you can see who has small kids on this mailing list :-) On 06 Apr 2013, at 08:38, stephane ducasse wrote: > How can I get fast the choices? > Because when I type > > printO > > and press tab I do not get > > printOn: > but > > printO | > Stef > > > >> fwiw, I changed the implementation of NECController to: >> - accept both and for code completion >> - still use to first complete the common prefixes, but a subsequent >> will select the suggestion >> >> i.e. this is the behavior in XCode, which imho is a very good one. >> >> _and_ I do not have to disable the completion of common prefixes if I want >> to disable for selection. >> >> Maybe people should give this a try and see? >> >> cheers >> Johan >> >> >> >> >> On 06 Apr 2013, at 02:18, Ben Coman wrote: >> >>> Alexandre Bergel wrote: +1 Alexandre On Apr 3, 2013, at 8:57 PM, Tudor Girba wrote: > +1 > > Doru > > > On Apr 4, 2013, at 2:19 AM, Igor Stasenko wrote: > > >> On 3 April 2013 22:45, Camillo Bruni wrote: >> >>> theres a setting to: >>> >>> - disable ENTER to accept the completion >>> - to increase the popup delay >>> >>> so I think that is invalid bug report then... >>> >>> >> i tend to disagree. >> The defaults which we have now in 2.0 for autocompletion >> is breaking my workflow badly too. >> >> Yes, i can go to settings and disable/reconfigure stuff but that doesn't >> nullifying the fact, that my workflow is broken with ambiguous and >> inconsistent >> reaction(s) to my keystrokes by UI if i keep defaults. >> >> For instance i am still clueless, why 'enter' is default for >> autocompletion, >> and disabling it and enabling 'tab' simply doesn't works. >> That leaves me with the only option: keep using 'enter' for >> autocompletion, if i ever want to use it. >> We have to fix that. >> >> >> >>> On 2013-04-03, at 22:23, "Sean P. DeNigris" >>> wrote: >>> >>> From https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardness : > The combination of enter on accept, with the current behavior to > select > the first completion suggestion by default = trouble. For example: > > 1. Type "printOn: aStream"... pretty common method start > 2. Hit enter to go to the next line > > You will now have "printOn: MCDataStream" WTF!! I get burned by this > pretty regularly and it's annoying. I'm not sure what the fix should > be... > probably no default selection in the suggestion menu, but possibly > only > when enter on accept is enabled (t would require an extra key press to > complete and when do you ever type a tab in the middle of a line?) > >>> I haven't used the 2.0 auto compeltion yet so I don't know if this is >>> relevant, but just a passing thought... When Microsoft Word muck up using >>> smart characters, one small saving grace is that it first enters my >>> original typing before "smart-ifying" it, such that ctrl-z undoes back to >>> my original typing. >>> >>> cheers -ben >>> >> > >
Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness
fwiw, I changed the implementation of NECController to: - accept both and for code completion - still use to first complete the common prefixes, but a subsequent will select the suggestion i.e. this is the behavior in XCode, which imho is a very good one. _and_ I do not have to disable the completion of common prefixes if I want to disable for selection. Maybe people should give this a try and see? cheers Johan NECController-Changes.cs Description: Binary data On 06 Apr 2013, at 02:18, Ben Coman wrote: > Alexandre Bergel wrote: >> +1 >> >> Alexandre >> >> >> On Apr 3, 2013, at 8:57 PM, Tudor Girba wrote: >> >> >>> +1 >>> >>> Doru >>> >>> >>> On Apr 4, 2013, at 2:19 AM, Igor Stasenko wrote: >>> >>> On 3 April 2013 22:45, Camillo Bruni wrote: > theres a setting to: > > - disable ENTER to accept the completion > - to increase the popup delay > > so I think that is invalid bug report then... > > i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too. Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults. For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that. > On 2013-04-03, at 22:23, "Sean P. DeNigris" wrote: > > >> From >> https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardness >> : >> >> >>> The combination of enter on accept, with the current behavior to select >>> the first completion suggestion by default = trouble. For example: >>> >>> 1. Type "printOn: aStream"... pretty common method start >>> 2. Hit enter to go to the next line >>> >>> You will now have "printOn: MCDataStream" WTF!! I get burned by this >>> pretty regularly and it's annoying. I'm not sure what the fix should >>> be... >>> probably no default selection in the suggestion menu, but possibly only >>> when enter on accept is enabled (t would require an extra key press to >>> complete and when do you ever type a tab in the middle of a line?) >>> >> > I haven't used the 2.0 auto compeltion yet so I don't know if this is > relevant, but just a passing thought... When Microsoft Word muck up using > smart characters, one small saving grace is that it first enters my original > typing before "smart-ifying" it, such that ctrl-z undoes back to my original > typing. > > cheers -ben >
Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness
On 04 Apr 2013, at 10:40, Esteban Lorenzano wrote: >> In any case, is it difficult to enable the both and ? > > yes and no... > I mean. It is easy, but is hardcoded in > > NECController>>handleKeystrokeBefore:editor: > > so... you can hack around there :) That is what I needed to know :-) cheers Johan
Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness
Hi Esteban, I tend to agree with your argument but... > about the current defaults, "enter" is the one that is choose for 99% of IDEs > around the world (and yes, the 1% default is probably just Pharo 1.4). All those IDEs offer both and to trigger code completion. If I enable in Pharo, the no longer works. I also wonder why I don't find the behavior annoying in other IDEs. Can it be the case that Smalltalk code has more 'line ends' that just terminate with a word? In many other languages, a code line is more often terminated with a non alphanumeric character (separators, braces, etc...). I am not sure about this but I wonder... In any case, is it difficult to enable the both and ? cheers, Johan
Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness
+1 btw, if I disable that selects the current suggestion, how can I select the suggestion without using the mouse? imho, should select the suggestion eventually. On 04 Apr 2013, at 09:06, "p...@highoctane.be" wrote: > +1 > Very annoying. > > > 2013/4/4 Igor Stasenko > On 3 April 2013 22:45, Camillo Bruni wrote: > > theres a setting to: > > > > - disable ENTER to accept the completion > > - to increase the popup delay > > > > so I think that is invalid bug report then... > > > > i tend to disagree. > The defaults which we have now in 2.0 for autocompletion > is breaking my workflow badly too. > > Yes, i can go to settings and disable/reconfigure stuff but that doesn't > nullifying the fact, that my workflow is broken with ambiguous and > inconsistent > reaction(s) to my keystrokes by UI if i keep defaults. > > For instance i am still clueless, why 'enter' is default for autocompletion, > and disabling it and enabling 'tab' simply doesn't works. > That leaves me with the only option: keep using 'enter' for > autocompletion, if i ever want to use it. > We have to fix that. > > > > On 2013-04-03, at 22:23, "Sean P. DeNigris" wrote: > > > >> From > >> https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardness > >> : > >> > >>> The combination of enter on accept, with the current behavior to select > >>> the first completion suggestion by default = trouble. For example: > >>> > >>> 1. Type "printOn: aStream"... pretty common method start > >>> 2. Hit enter to go to the next line > >>> > >>> You will now have "printOn: MCDataStream" WTF!! I get burned by this > >>> pretty regularly and it's annoying. I'm not sure what the fix should be... > >>> probably no default selection in the suggestion menu, but possibly only > >>> when enter on accept is enabled (t would require an extra key press to > >>> complete and when do you ever type a tab in the middle of a line?) > >> > >> > >> > >> > >> > >> - > >> Cheers, > >> Sean > >> -- > >> View this message in context: > >> http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4679488.html > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > > > > > > > > -- > Best regards, > Igor Stasenko. > >
Re: [Pharo-project] Web testing with Pharo
On 03 Apr 2013, at 15:29, Tobias Pape wrote: > do you mind me making Parasol ready for Squeak? > If so, would you grant me access on the repo? Done! Just make sure it continues working in Pharo ;-) Johan
Re: [Pharo-project] Web testing with Pharo
Hi Torsten, We were using WebTester first but created Parasol to replace it. WebTester was written for Selenium RC (aka Selenium 1). It uses a protocol you can find somewhere here: http://docs.seleniumhq.org/docs/05_selenium_rc.jsp Beach-Parasol is written for Selenium Webdriver (aka Selenium 2). It uses this protocol: http://code.google.com/p/selenium/wiki/JsonWireProtocol More info on using Parasol: http://ss3.gemstone.com/ss/Parasol.html/Wiki greetings Johan On 03 Apr 2013, at 14:50, Torsten Bergmann wrote: > There is > Parasol http://ss3.gemstone.com/ss/Parasol.html and > Webtester http://www.squeaksource.com/WebTester/ > > both for Pharo and both using Selenium driver to test web apps. > > Anyone able to describe the differences or experience? > Why two projects instead of one? > > Thx > T. >
Re: [Pharo-project] Gettext in Pharo2.0
Okay, I can take care of this. On 03 Apr 2013, at 11:42, stephane ducasse wrote: > There is a PharoExtras/Gettext projects. > > Stef > >> I propose to make a Gettext repository on smalltalkhub. >> We can move Gettext and its Seaside extension there. >> >> If you want to include it in the release (which would be great), we need to >> factor out some code because there is an overlap with >> System-Internationalization. >> >> Hilaire, if you are fine with this, I can take care of it. >> >> cheers >> Johan >> >> On 02 Apr 2013, at 19:38, Hilaire Fernandes >> wrote: >> >>> Le 02/04/2013 18:33, Paul DeBruicker a écrit : I think Gettext should be in its own place, and I don't think there is one for it yet. I think Gettext that worked in 1.3 also doesn't work in Pharo 1.4, which I could look at fixing. Or if it does work in 1.4 let me know how to load it. >>> >>> >>> This version works for Pharo 1.4: >>> >>> Gofer new >>> url: 'http://www.squeaksource.com/PharoNonCorePackages'; >>> package: 'ConfigurationOfGettext'; >>> load. >>> (Smalltalk at: #ConfigurationOfGettext) perform:#load. >>> >>> Hilaire >>> >>> >>> -- >>> Dr. Geo http://drgeo.eu >>> >>> >> >> > >
Re: [Pharo-project] Gettext in Pharo2.0
I propose to make a Gettext repository on smalltalkhub. We can move Gettext and its Seaside extension there. If you want to include it in the release (which would be great), we need to factor out some code because there is an overlap with System-Internationalization. Hilaire, if you are fine with this, I can take care of it. cheers Johan On 02 Apr 2013, at 19:38, Hilaire Fernandes wrote: > Le 02/04/2013 18:33, Paul DeBruicker a écrit : >> I think Gettext should be in its own place, and I don't think there is one >> for it yet. I think Gettext that worked in 1.3 also doesn't work in Pharo >> 1.4, which I could look at fixing. Or if it does work in 1.4 let me know >> how to load it. > > > This version works for Pharo 1.4: > > Gofer new > url: 'http://www.squeaksource.com/PharoNonCorePackages'; > package: 'ConfigurationOfGettext'; > load. > (Smalltalk at: #ConfigurationOfGettext) perform:#load. > > Hilaire > > > -- > Dr. Geo http://drgeo.eu > >
[Pharo-project] Gettext in Pharo2.0
Hi, Loading Gettext into Pharo2.0 crashes badly (system locks up, eventually an emergency debugger appears). The reason is the class initialization of NaturalLanguageTranslator: Smalltalk addToStartUpList: NaturalLanguageTranslator after: FileDirectory. Because the class FileDirectory is no longer in that list, it crashes. So, my questions: - should it not produce a nicer debugger window? - I can fix the load problem itself and also take a look to port this package to Pharo2.0 if it requires more than adapting the above. But I have no write access to the PharoNonCorePackages repository. Is there a new location? Or is there already a version for Pharo2.0 somewhere? Or should we move it out of that repository and give it it's own special place? cheers Johan
Re: [Pharo-project] FileSystem-Legacy fixes
Allright. I will take care of that. Johan (sent from my mobile) On 30 Mar 2013, at 20:54, Camillo Bruni wrote: > Yes that sounds like a good idea. > and we should move it then to PharoExtras. > > I created http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy/ and added > you as a contributor. > Could you copy over the contents from http://smalltalkhub.com/#!/~dh83/fisleg > ? > and maybe create a configuration? > > thanks a lot! > > On 2013-03-30, at 09:17, Johan Brichau wrote: > >> Hi Pharoers, >> Hi Camillo, >> >> To make Seaside3.0.x work in Pharo2.0, we included the FileSystem-Legacy >> package. >> (this is probably the easiest solution for Seaside3.0.x branch) >> >> I did need to make some changes because this package had a slightly >> different behavior than the legacy code in some methods: >> - add #primPathNameDelimiter >> - #directoryExists: should not only check if it exists, it should also check >> if it's a directory: >>(self resolve: filenameOrPath) exists and:[(self resolve: filename) >> isDirectory] >> - #directoryNamed: was actually able to accept a fully qualified pathName as >> an argument (not logical, but that's legacy ;-). So implemented as follows: >>FileDirectory on: (self fullNameFor: localFileName) >> >> What do you think? >> Can I publish these changes to the FileSystem package? >> >> regards >> Johan >
[Pharo-project] FileSystem-Legacy fixes
Hi Pharoers, Hi Camillo, To make Seaside3.0.x work in Pharo2.0, we included the FileSystem-Legacy package. (this is probably the easiest solution for Seaside3.0.x branch) I did need to make some changes because this package had a slightly different behavior than the legacy code in some methods: - add #primPathNameDelimiter - #directoryExists: should not only check if it exists, it should also check if it's a directory: (self resolve: filenameOrPath) exists and:[(self resolve: filename) isDirectory] - #directoryNamed: was actually able to accept a fully qualified pathName as an argument (not logical, but that's legacy ;-). So implemented as follows: FileDirectory on: (self fullNameFor: localFileName) What do you think? Can I publish these changes to the FileSystem package? regards Johan
Re: [Pharo-project] Looking for a Seaside 3.1 Configuration for Pharo 2.0
I think it's not a good idea to dump the 3.0.x branch Many people are using that + 3.1 is still in development On 28 Mar 2013, at 10:32, stephane ducasse wrote: > thanks Paul. > > I should say that I would have love not to have > 3.0.1. > 3.0.2 > so I'm really eager to get seaside 3.1 out > but at least something that can be marketed as movement. > > Stef > On Mar 27, 2013, at 11:29 PM, Paul DeBruicker wrote: > >> Stéphane Ducasse wrote >>> Hi guys >>> >>> we would like to use seaside to validate the VM and also make sure that >>> Seaside31. works perfectly in Pharo2.0. >>> I saw that some of you have a working configuration. Where can we find it >>> because we would like to publish it in the >>> MetaRepoForPharo20. >>> >>> Stef >> >> >> 3.1 is not released. That being said see if this set of packages works for >> you >> >> http://dl.dropbox.com/u/4460862/seaside31Config.zip >> >> but they are also not official versions of anything and the official ones >> will likely be different. they are just something I cobbled together that >> seemed to work at the beginning of the month. >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Looking-for-a-Seaside-3-1-Configuration-for-Pharo-2-0-tp4678580p4678638.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >
Re: [Pharo-project] Looking for a Seaside 3.1 Configuration for Pharo 2.0
I'm merging mine and Paul's configuration for Seaside 3.0.7 into Diego's and Stefan's work. Of course, there's always stuff that gets in the way of finishing that (like moving our offices ;-). I hope to have one by end of the week for Seaside 3.0.7. The intention is that we merge this into the Seaside3.1 configuration. On 27 Mar 2013, at 18:28, Stephan Eggermont wrote: > Stef wrote: >> we would like to use seaside to validate the VM and also make sure that >> Seaside31. works perfectly in Pharo2.0. >> I saw that some of you have a working configuration. Where can we find it >> because we would like to publish it in the >> MetaRepoForPharo20. > > We have it working, but it does not have the Seaside Panel (& browser). At > last Esug Seaside sprint I started redoing > them in Spec, but never managed to spend more time on them. They are in the > Seaside31 repository > on squeaksource: Seaside-Pharo-Tools-Spec (might need renaming to Pharo20). > > Stephan > > > >
Re: [Pharo-project] pharo on ipad3 -- tiny image shown only
Hi Esteban, Thanks for sharing the secret ;-) I checked out latest sources and ran ConfigurationOfPharoVM version 2.0-4 but it does not work out-of-the-box. Right now, I just forced to always use the SqueakUIViewCALayer. Need to check why it took the other one.. Johan On 17 Sep 2012, at 22:34, Esteban Lorenzano wrote: > secret is not use OpenGL but CALayer... ensure you start with > SqueakUIViewCALayer instead SqueakUIViewOpenGL (btw... if you were using my > sources, that should be out of the box). > > I'm working to doit with a better mechanism (OpenGL or CG), but so far... no > time :) > > Esteban > > On Sep 17, 2012, at 10:56 AM, Hilaire Fernandes > wrote: > >> Esteban should be able to tell. >> >> Hilaire >> >> > >
Re: [Pharo-project] pharo on ipad3 -- tiny image shown only
Thanks for the response, but unfortunately it does not seem to help.
I'm a bit amazed because the Dr Geo app works perfectly fine. So where is the
trick?
On 16 Sep 2012, at 19:24, p...@highoctane.be wrote:
> In another application, I do have this thing that helps in rescaling
> (the class is a XXXView)
>
> // Enable retina display
> if( CFG_IOS_RETINA_ENABLED ){
> if( [self
> respondsToSelector:@selector(contentScaleFactor)] ){
> float scaleFactor=[[UIScreen mainScreen] scale];
> [self setContentScaleFactor:scaleFactor];
> }
> }
>
> This is a quickfix that will look ugly but... worth trying.
>
> Add that into the SqueakUIView.m file inside this:
>
> - (id)initWithFrame:(CGRect) aFrame {
> self = [super initWithFrame: aFrame];
> self.autoresizingMask =
> UIViewAutoresizingFlexibleRightMargin|UIViewAutoresizingFlexibleBottomMargin|UIViewAutoresizingFlexibleHeight|UIViewAutoresizingFlexibleWidth;
> colorspace = CGColorSpaceCreateDeviceRGB();
> return self;
> }
>
> I suspect that self.autoresizingMask is the culprit...
>
> Hope it helps.
>
> Phil
>
> 2012/9/16 Igor Stasenko :
>> On 16 September 2012 18:14, Johan Brichau wrote:
>>> Hi everyone,
>>>
>>> After some very friendly help of Nick and Igor at ESUG, I managed to get
>>> the iStackVM running on my iPad again, thanks a lot guys!
>>>
>>> However, the image now shows up on only a very small portion of the screen.
>>> Is that a known issue?
>>
>> yes. this is a "retina display" issue. :)
>> I am not sure what is the status, however i can assure you that we
>> (especially Esteban) is well aware of it.
>>
>>>
>>> btw: the problem I experienced to compile the vm correctly was eventually a
>>> package-loading problem (i.e. I did not get the correct packages). This is
>>> because there is a bug in the version-method generation of Metacello.
>>> Together with Dale, we discussed that issue and Dale just solved it last
>>> friday.
>>>
>>> Johan
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
[Pharo-project] pharo on ipad3 -- tiny image shown only
Hi everyone, After some very friendly help of Nick and Igor at ESUG, I managed to get the iStackVM running on my iPad again, thanks a lot guys! However, the image now shows up on only a very small portion of the screen. Is that a known issue? btw: the problem I experienced to compile the vm correctly was eventually a package-loading problem (i.e. I did not get the correct packages). This is because there is a bug in the version-method generation of Metacello. Together with Dale, we discussed that issue and Dale just solved it last friday. Johan
Re: [Pharo-project] thanks for pharoconf
Yes, it was really nice. Thanks for such a good atmosphere! I regret I was unable to be there on Friday. Of course, I hope to see you all at ESUG in Gent! ;-) Johan (sent from my mobile) On 27 May 2012, at 12:58, "p...@highoctane.be" wrote: > Yes, very interesting, motivating, and results producing! > > Thanks a ton for making it a reality. > > Two blog posts of mine just in case you are interested: > > http://philippeback.be/2012/05/first-day-of-pharoconf-in-lille/ > http://philippeback.be/2012/05/second-day-at-pharoconf-in-lille/ > > Thanks again! > > Philippe Back > > 2012/5/27 Norbert Hartl > Yes, > > was fun to see a lot of you. And I could add some new faces to my inventory. > Great! > > Norbert > > Am 27.05.2012 um 00:12 schrieb Tudor Girba: > > > Hi, > > > > I had a good time at PharoConf. > > > > Thanks for organizing it. > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "Beauty is where we see it." > > > > > > > > > > > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: p...@highoctane.be | > Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges >
Re: [Pharo-project] Pharo 1.4: unable to load packages from webdav http repository
Hey Sven, Thanks for the response! By tracing, I also just noticed that our webserver returned 'text/plain' mimetype instead of a binary one. It was our fault. Zinc is cool, just too bad it exposed our errors now ;-) Cheers! Johan On 06 Apr 2012, at 09:41, Sven Van Caekenberghe wrote: > Dag Johan, > > On 06 Apr 2012, at 08:58, Johan Brichau wrote: > >> Hi everyone, >> >> I'm test-driving Pharo 1.4 beta and I'm getting an error loading any package >> from our webdav-based monticello repository. >> The error surfaces in the reading of the zipfile by monticello, but it seems >> the source of the problems is the replacement of sockets by Zinc sockets: >> >> It seems that Zinc's "get" returns a ByteString instance when getting the >> file (in method MCHttpRepository>>#readStreamForFileNamed:do:) from the >> webdav volume. In contrast, when I'm loading a package from squeaksource, it >> returns a ByteArray. >> >> The reading of the zip goes wrong because the stream is returning characters >> instead of bytes. So I guess the difference between the ByteString and the >> ByteArray is the source of that problem. >> >> Maybe anyone knows why this happens? >> In the meantime... I'm digging deeper >> >> Johan > > Yes, this sounds familiar: Zn is much more strict at the HTTP level, most > probably your server returns a text mime-type. Hence Zn interprets this as a > string. Take one of your packages' URLs and do: > > ZnEasy get: 'http://my-web-dav/repo/Code.123.mcz'. > > and inspect the results, you'll see the mime type there. Compare it to, for > example: > > ZnEasy get: > 'http://mc.stfx.eu/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenberghe.254.mcz' > > The solution is to fix your server to use any binary mime-type for .mcz files > (application/octet-stream or even application/x-monticello). > > Sven > > PS: Zinc does not 'replace sockets', it is an HTTP client using regular > socket[streams].
[Pharo-project] Pharo 1.4: unable to load packages from webdav http repository
Hi everyone, I'm test-driving Pharo 1.4 beta and I'm getting an error loading any package from our webdav-based monticello repository. The error surfaces in the reading of the zipfile by monticello, but it seems the source of the problems is the replacement of sockets by Zinc sockets: It seems that Zinc's "get" returns a ByteString instance when getting the file (in method MCHttpRepository>>#readStreamForFileNamed:do:) from the webdav volume. In contrast, when I'm loading a package from squeaksource, it returns a ByteArray. The reading of the zip goes wrong because the stream is returning characters instead of bytes. So I guess the difference between the ByteString and the ByteArray is the source of that problem. Maybe anyone knows why this happens? In the meantime... I'm digging deeper Johan
Re: [Pharo-project] Which COG VM?
I think somebody that maintains the website needs to replace the VM that is linked on the download page with the latest VM built in Jenkins. I had the same issues but when I switched to the latest built on Jenkins, I had no issues anymore. On 20 Jan 2012, at 22:31, Stéphane Ducasse wrote: > On which machines are working your students? > Because on mac we do not see any problems. > BTW do you machine (windows) have tune off the virus check because this is > often a cause for trouble. > > >> The latest COG VM, pointed to from the Pharo-project download page, >> CogVM-*-13307.zip, seems to be a little unstable. Many students have been >> reporting that it just hangs while doing nothing more than editing (not >> saving) text, and I have seen long hangs while doing trivial things — these >> look to me like synchronization bugs. >> >> The COG that I used about a year ago (Jann–March 2011 timeframe), in >> contrast, seemed rock solid, although it might have been slower. >> >> I have two questions. First, where can I find an archive of PRE_BUILT VMs. >> I don't want to give my students (or myself) the task of building a VM from >> scratch. >> >> Second, how can I find out what version of COG I'm running? SmalltalkImage >> current versionLabel doesn't work. SmalltalkImage current buildDate gives >> me a date, but how does that relate to the version numbers that I see in on >> the COG web site? >> >> Thanks. I want my students to have a good starting experience with Pharo, >> and they are not. They are messing around trying to retrieve source from >> hosed images :-( > > This is really strange because we work all with Pharo like mad and we do not > experience that and some of us are really doing crazy think like swapping > class and their instances out of the image, or generation assembly on the > fly, or changing the event loop… > > >> >> Andrew >> >> >> >> > >
Re: [Pharo-project] Optimisation / Simplification ...
Hi, With the exception of any return statement in , which should do a non-local return instead of returning from the block. I just read an interesting post on why functions (or methods) are not blocks: http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ best, Johan On 10 Jan 2012, at 01:52, James Ladd wrote: > > While implementing Redline Smalltalk it occurred to me that methods and > blocks > are the same things, making the use of blocks to represent methods a possible > optimisation or simplification to the internal of any Smalltalk > implementation. > > For example, > > at: key put: value > > > Is not that different to: > > at:put: [ :key :value | ] > > Just saying.
Re: [Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307
On 21 Dec 2011, at 22:05, Stéphane Ducasse wrote: > doing what? Just serving a Seaside app (but that makes it a quite broad 'cause') I was hoping the crashlog points out where the problem is. > on which platform? mac? Yes, mac (it's mentioned in my email ;-) > Did you try the latest version on jenkins because esteban merged changes? not yet, I just downloaded that one too and will try. My main point is that these two artefacts are the ones who are offered directly on the Pharo website. So people trying it, will probably experience these things to. By downloading another VM, my problem was solved, but not everybody knows about all these different options. So, I will try the latest VM from jenkins and let you know… thanks for the feedback! Johan
[Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307
Hi, I have been running Pharo 1.3 (#13315) with a pre-built Cog VM's downloaded from Eliot's site in a reliable manner (i.e. very few crashes) for many months. Just last week, I decided to try the Cog VM that is served from the Pharo website (Cog VM Mac-13307) and I am experiencing continuous crashes of the image. I am attaching a dump to this email. Once I switched back to the latest VM served on Eliot's site (VM.r2522), I stopped experiencing these crashes. If I experience this, probably other are too… cheers, Johan crash.dmp Description: Binary data
Re: [Pharo-project] gt inspector
I am ;-) After a quick look some weeks ago, I have just recently made it part of our automatic development builds. I really like this kind of inspector view. On 21 Dec 2011, at 09:01, Tudor Girba wrote: > Hi, > Just out of curiosity: Does any of you use the GTInspector? > For those that wonder what that is, here is a > demo:http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk > This is available in any recent Moose image mapped as Explorer (CMD+I). > You can load it in a Pharo 1.3 image by:Gofer new squeaksource: > 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load.(Smalltalk > at: #ConfigurationOfGlamoroust) loadDefault.(Smalltalk at: > #GTInspector) registerToolsOn: Smalltalk tools. > > Cheers,Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" >
Re: [Pharo-project] Policy for storing metacello configurations
Maybe a bit of wishful thinking but… Ideally, I think of the metacellorepository as a kind of 'smart folder' where all metacello configurations of public repositories are automatically included. Something like a smart mail folder on mac mail. Having two locations with the same package almost always leads to confusion / mistakes / forgetting / etc… Would such an 'automatic' repository be possible to implement in squeaksource3 and/or smalltalk hub? Johan On 17 Aug 2011, at 20:01, Stéphane Ducasse wrote: > > The policy should be > - put a configurationOf in your package > - publish when you want a copy of it in metacellorepository > > I will sit with dale sunday because we want the "publish" to copy all the > dependent package also in the DistributionMetacelloRepository > > On Aug 17, 2011, at 8:59 AM, Max Leske wrote: > >> I would like to complain a bit about the current way Metacello >> configurations are distributed in different repositories. I ended up using >> the wrong configuration for two different projects twice in just two days. >> Apart from the date in the configuration file (and possibly the version >> number, although that's not as reliable) there's no easy way to tell which >> configuration is the most recent. >> >> Some people seem to have adopted MetacelloRepository as the standard >> repository for all configurations, others keep the configuration for a >> project in the project repositories and a third group uses both repositories >> (where one repository contains outdated versions of course…). >> >> Can we please agree on a simple policy on where to store the configuration >> for a project? I am sure that this would make life easier for all of us. >> >> Cheers, >> Max > >
Re: [Pharo-project] Squeaksource is down :(
On 07 Aug 2011, at 18:36, Lukas Renggli wrote: > Again and again, automatic restart is not possible with SqueakSource > because it requires manual intervention after startup to make sure the > model is properly loaded and consistent. People are not stupid. ha ok, I did ask the question before but never got an answer. I hope that the new SmalltalkHUB and SS3 people prepare to not integrate a human being into their system. thanks for the info. cheers, Johan
Re: [Pharo-project] Squeaksource is down :(
Just my 2 cents: install monit (http://mmonit.com/) and let monit restart the system when it's down it takes 5 minutes to setup and I can help (I have it running myself) Johan On 07 Aug 2011, at 17:07, Stéphane Ducasse wrote: > would be cool. > Nicolas told me that he was working hard to get Smalltalkhub running well and > he is right. > As soon as it will be available it will gets stressed :) > > > On Aug 7, 2011, at 5:01 PM, Janko Mivšek wrote: > >> Guys, I can add SqueakSource (and other important sites) to my Nagios >> monitoring, so that you'll get email immediately when such site will be >> down. >> >> Best regards >> Janko >> >> S, Jorge Ressia piše: >>> It is working >>> Cheers, >>> >>> On Sun, Aug 7, 2011 at 4:45 PM, Stéphane Ducasse >>> wrote: >> >> >> -- >> Janko Mivšek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > >
Re: [Pharo-project] loading OSProcess in Pharo1.3
You are right... except that I am not using a ConfigurationOfOSProcess strange... my metacello config just points to the repository and loads the OSProcess package... why is it loading an older version? probably another config that I am loading that points to it? ... argh... thanks, at least I know now :-) On 10 Jul 2011, at 20:08, Mariano Martinez Peck wrote: > yes, it was. Probable nobody updated ConfigurationOfOSProcess as Johan is > loading an old version. Try getting the last one or use #bleedingEdge > > On Sun, Jul 10, 2011 at 3:16 PM, Stéphane Ducasse > wrote: > strnage I thought the new version of OS Process fixed that. > > On Jul 10, 2011, at 3:03 PM, Johan Brichau wrote: > > > Hi guys, > > > > I'm (finally) trying out the new Pharo1.3 > > Yesterday I had a couple of issues with build 13284 but 13285 seems to fix > > these. > > > > Great! > > > > But I'm now trying to load OSProcess in Pharo 1.3 and OSProcess tries to > > add its image startup script to the list right after ImageSegment's image > > startup script. > > However, it appears that #ImageSegment is no longer in the startup list, > > which yields an error. > > > > I don't know if this is expected, so I thought I should email it here. > > > > For now, I changed OSProcess so that it adds its startup script right after > > SmalltalkImage instead. > > I'm not sure if that is OK though... it's just a quick fix I made right > > now. I'm not sure what the prerequisites of OSProcess are in that respect. > > > > Any thoughts? > > > > Johan > > > > > > -- > Mariano > http://marianopeck.wordpress.com >
[Pharo-project] loading OSProcess in Pharo1.3
Hi guys, I'm (finally) trying out the new Pharo1.3 Yesterday I had a couple of issues with build 13284 but 13285 seems to fix these. Great! But I'm now trying to load OSProcess in Pharo 1.3 and OSProcess tries to add its image startup script to the list right after ImageSegment's image startup script. However, it appears that #ImageSegment is no longer in the startup list, which yields an error. I don't know if this is expected, so I thought I should email it here. For now, I changed OSProcess so that it adds its startup script right after SmalltalkImage instead. I'm not sure if that is OK though... it's just a quick fix I made right now. I'm not sure what the prerequisites of OSProcess are in that respect. Any thoughts? Johan
Re: [Pharo-project] JavaConnect?
Hi Alex, JavaConnect has never been finished for Pharo. I worked on it with the idea to also include an abstraction layer over Alien but it proved to be much more work than I thought. Coen is actively using and maintaining the Visualworks version. I really hope that I can port is someday, but right now it's just not possible for me. Johan On 26 Jun 2011, at 03:00, Alexandre Bergel wrote: > Hi! > > Does JavaConnect work with the last Pharo? I cannot install it apparently. > Loading it via the configuration freezes the image. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >
Re: [Pharo-project] SS is down
I wonder: why is there not automatic restart script? It seems a bit silly that a human is now part of the squeaksource system itself... to restart it. On 18 Jun 2011, at 08:54, laurent laffont wrote: > ... sad because it's raining here .. > > Laurent
Re: [Pharo-project] Report generation? (I need an update)
On 08 Jun 2011, at 17:37, Esteban Lorenzano wrote: > So... my question: > what do you use to generate reports to clients? > if pdf generation... which strategy? We use Jasper reports: www.jasperforge.org It's a feature-rich library for generation of any report to about any format you can think of, and it's open source. The downside is: it is a Java library but we use http communication between our Seaside app and the jasper application. In the future, I hope to get my own Javaconnect library (working in Visualworks) rolling completely in Pharo to have native communication from Pharo to Java. In the meantime, you might try JNIPort since that one has Pharo version already. We can try to develop everything in Smalltalk but we will fail to keep up. Johan
Re: [Pharo-project] Gettext package?
Ok thanks Hilaire. I will take a look at the current state of the package in etoys and split up the code as I mentioned. I'm new to this kind of internationalization stuff, so I will do some work as part of internationalizing our web apps. On 24 May 2011, at 23:13, Hilaire Fernandes wrote: > I ported the gettext package from Etoys to Pharo with help of other > (Henrik). > I have to admit I mostly forgot about its internal, even if I amn using > it for DrGeo. > In between, some part of the gettext package in Etoys was improved, I > forgot which part exactly. Bert may remember a bit more. > > Do whatever you think is appropriate with the package. As you hacked the > package recently you are definitely in a better position to split it in > different component. > > Hilaire > > Le 24/05/2011 11:11, Johan Brichau a écrit : >> Hi guys, >> >> What is the future of the Gettext package in the PharoNonCorePackages >> repository? >> Is the intention to include it in Pharo core? Should that package become a >> separate project? Something else? >> >> I am asking this because I am using it for internationalization support in >> our Seaside apps (together with the Gettext-Seaside package by Philippe >> Marschall). >> Hence, I created a port of the relevant parts to GemStone, following the >> "develop in Pharo, deploy in GemStone" philosophy. >> >> Now, the ported package is a complete duplicate + appropriate changes, but >> it's better if we create a common package and separate the platform-specific >> parts out. >> But I would not want to interfere with anyone's plans, specifically Hilaire >> Fernandes' plans, probably (who seems to be the author of the package). >> >> So, I would like to get in touch with the stakeholders of the package and >> discuss where it's going. >> >> cheers >> Johan >> >> (see more info below -- mails >> >> >> Begin forwarded message: >> >>> From: Johan Brichau >>> Date: 24 May 2011 08:26:33 GMT+02:00 >>> To: Philippe Marschall >>> Cc: GemStone Seaside beta discussion >>> Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to >>> Gemstone >>> Reply-To: GemStone Seaside beta discussion >>> >>> Hi Philippe, >>> >>> Yes, those are classes I left out (but they don't have the WA prefix). >>> >>> I also prefer that there is a shared common package for both platforms but >>> there are more differences spread over several methods. >>> Off the top of my head, most differences are located in the MOFile class. >>> Also, the 'startup' methods that are used to trigger a locale refresh when >>> starting the Pharo image are not applicable in Gemstone. >>> >>> I'm willing to work towards a common package + platform-specific packages. >>> Probably, we have to hear what the Pharo people (and specifically Hilaire >>> Fernandes) think about it. >>> >>> cheers >>> Johan >>> >>> On 23 May 2011, at 20:08, Philippe Marschall wrote: >>> >>>> 2011/5/23 Johan Brichau : >>>>> Hi all, >>>>> >>>>> The Gettext [1] implementation of Pharo has now been ported to Gemstone, >>>>> such that we can use it for internationalization in web applications >>>>> together with Gettext-Seaside. >>>>> More precisely, the Gettext package is a prerequisite for Gettext-Seaside. >>>>> >>>>> With the "develop in Pharo, deploy in Gemstone" philosophy, I ported only >>>>> those parts that are required to deploy the translation files in the >>>>> Seaside web apps. >>>>> The implementation that generates translation files from the codebase is >>>>> a bit more entrenched into platform-specific libraries. So, one has to >>>>> generate the translation catalogs to disk in Pharo, edit them with a tool >>>>> like poedit, and deploy the locale with the Gemstone deployment. >>>> >>>> Clever. I guess WAGetTextExporter and WATranslatedArgumentsFinder are >>>> the classes that don't work in Gemstone. If so I could split the >>>> package into a portable part and a Pharo part so you don't need to >>>> load them im GemSonte. >>>> >>>> Cheers >>>> Philippe >>> >> >> >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >
Re: [Pharo-project] Gettext package?
On 25 May 2011, at 11:34, Stéphane Ducasse wrote: >> But does it belong into that what we call Pharo? > > yes probably. If you want to keep and improve the existing "localisation & translation" support, I think it's a good idea to integrate Gettext. It uses a format that is used beyond the Smalltalk community. But I guess the above depends wether the 'core' Pharo tools require some "translation" support. And I don't think they do, i.e: I don't think we want a french version of the system browser ;-) They might require "localisation" without the translation (i.e. date format etc.) but Gettext is not about that. Any internationalization support is more a package to be used by applications developed in Pharo. My use of Gettext, for example, is for translation support in Seaside apps. Hilaire uses it for Dr. Geo. Of course, GemStone and Visualworks also come with an internationalization library integrated in the basic image (not entirely sure about VW). If I do more work using Gettext, I can certainly do something for its integration in Pharo. Johan
[Pharo-project] Gettext package?
Hi guys, What is the future of the Gettext package in the PharoNonCorePackages repository? Is the intention to include it in Pharo core? Should that package become a separate project? Something else? I am asking this because I am using it for internationalization support in our Seaside apps (together with the Gettext-Seaside package by Philippe Marschall). Hence, I created a port of the relevant parts to GemStone, following the "develop in Pharo, deploy in GemStone" philosophy. Now, the ported package is a complete duplicate + appropriate changes, but it's better if we create a common package and separate the platform-specific parts out. But I would not want to interfere with anyone's plans, specifically Hilaire Fernandes' plans, probably (who seems to be the author of the package). So, I would like to get in touch with the stakeholders of the package and discuss where it's going. cheers Johan (see more info below -- mails Begin forwarded message: > From: Johan Brichau > Date: 24 May 2011 08:26:33 GMT+02:00 > To: Philippe Marschall > Cc: GemStone Seaside beta discussion > Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to > Gemstone > Reply-To: GemStone Seaside beta discussion > > Hi Philippe, > > Yes, those are classes I left out (but they don't have the WA prefix). > > I also prefer that there is a shared common package for both platforms but > there are more differences spread over several methods. > Off the top of my head, most differences are located in the MOFile class. > Also, the 'startup' methods that are used to trigger a locale refresh when > starting the Pharo image are not applicable in Gemstone. > > I'm willing to work towards a common package + platform-specific packages. > Probably, we have to hear what the Pharo people (and specifically Hilaire > Fernandes) think about it. > > cheers > Johan > > On 23 May 2011, at 20:08, Philippe Marschall wrote: > >> 2011/5/23 Johan Brichau : >>> Hi all, >>> >>> The Gettext [1] implementation of Pharo has now been ported to Gemstone, >>> such that we can use it for internationalization in web applications >>> together with Gettext-Seaside. >>> More precisely, the Gettext package is a prerequisite for Gettext-Seaside. >>> >>> With the "develop in Pharo, deploy in Gemstone" philosophy, I ported only >>> those parts that are required to deploy the translation files in the >>> Seaside web apps. >>> The implementation that generates translation files from the codebase is a >>> bit more entrenched into platform-specific libraries. So, one has to >>> generate the translation catalogs to disk in Pharo, edit them with a tool >>> like poedit, and deploy the locale with the Gemstone deployment. >> >> Clever. I guess WAGetTextExporter and WATranslatedArgumentsFinder are >> the classes that don't work in Gemstone. If so I could split the >> package into a portable part and a Pharo part so you don't need to >> load them im GemSonte. >> >> Cheers >> Philippe >
Re: [Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)
thanks guys! I didn't test in 1.3 indeed. btw, since moving to 1.2, after doing pullup or pushdown refactorings, I often get methods that badly reference instance variables. Their instvar index seems to be off in the sense that the name references another variable. I can fix the problem by recompiling the method but it's quite a pain. Unfortunately, I have been unsuccessful in creating a scenario that always works... I hope to do that asap.
[Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)
Hi, In Pharo1.2.x, I get an infinite recursion of a debugger windows opening when I load a metacello config that has a problem in it. The relevant problem can be reconstructed (without the infinite loop :-) by evaluation the following: (MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) decompileWithTemps I'm absolutely no compiler guy, so I'm totally unaware of what is happening. But it's serious because I cannot debug the actual problem of the metacello config because of this. It was tried with Pharo1.2.1 and Pharo1.2.2-12353 and latest Cog VM (27 April 2011). I entered issue 4241 in the bug tracker for this. Johan
Re: [Pharo-project] Popularity of Smalltalk in Software Industry
On 06 May 2011, at 12:57, Stefan Marr wrote: > Unfortunately, Smalltalkers don't know anything outside the image... Exactly, and most of the time, it's all you need. I remark a funny difference between developing in Smalltalk and developing in any other language (say, Java, Javascript, Objective-C, ...): When I program in Smalltalk, I have a lot of open code browsers in my image When I program in Java/Javascript/..., I have a lot of open web pages on my desktop That surely does not invalidate the need for more and better documentation. The documentation for Alien I saw 2 years ago was just sad. But when you compare FFI and Alien with the DLLCC of Visualworks, Stef is *definitely* right too. I started out building a layer for Alien some time ago (in the context of JavaConnect for Pharo) but I eventually had to stop... (making a living takes time too). Johan
Re: [Pharo-project] Making cr to autocomplete as well as tab (in Pharo 1.3)
On 06 May 2011, at 04:59, Jimmie Houchin wrote: > As I stated in my reply I like the idea of using CR. But you do raise a valid > point and demonstrate a valid situation. When CR was in there before, it was absolutely irritating. I had to put a space before hitting return just to prevent a completion. In my case, it always happened when typing the method header. > My question is... > Why isn't OCompletion offering the shortest options first? OCompletion's ordering is based on your recent activity. See http://www.inf.unisi.ch/phd/robbes/papers/ASE2008-completion.pdf In my opinion, this works really great. > If it did so, then your situation wouldn't occur. > tree would be selected before treeLayout. no, because the situation also occurs when you are typing a new message that does not exist yet. If we want to improve completion, I think we should take a look at XCode's completion. It works *very* nice for completion of keyworded message syntax. Johan
Re: [Pharo-project] Popularity of Smalltalk in Software Industry
That is a superb response, Toon! I could not agree more. Let me add to that Smalltalk is not dead. It's the stealth weapon of mass productivity used by small technology startups ;-) Johan On 05 May 2011, at 09:58, Toon Verwaest wrote: > Hi, > > I can tell you that independent of how the industry might perceive the > language Smalltalk, learning Smalltalk will make you personally a better > software engineer. And this is what the industry does want. You will look at > programming from a new angle and this will give you an edge. > > This is also true for learning other old languages like Scheme or Lisp. As > long as you stay within your Java / .NET bubble you will be one in a billion. > If you learn Smalltalk, the fact you know something that other people might > not makes you more special. The only negative part of learning Smalltalk > while working on other types of applications is that you will eat your shoe > 95% of the time hating that Java / .NET aren't more evolved and flexible :) > > As it seems that you are already working on a project revolving around > Smalltalk, be very happy that you are getting the opportunity to learn it; > you'll come out for the better. > > Lastly, don't care too much about popularity within industry. If you take the > time to learn the systems for yourself you will probably learn to understand > the differences yourself. You are currently also part of industry and > obviously don't know Smalltalk well yet; how informed was your decision to > not know Smalltalk? You are part of "the industry" making other people not > choose Smalltalk based on your (non-)choice of not using Smalltalk; if they > would all think this way! Sheep won't change anything :) > > cheers, > Toon > > On 05/05/2011 07:38 AM, sourav roy wrote: >> >> Hi All, >> >> I have just started my career in Software/IT industry and got into a project >> which involes enhancement/maintainance of product built in Smalltalk. >> >> I was never exposed to this language before and have no idea if it is used >> in the Industry as popularly as JAVA and .NET and looks like its a DEAD >> >> language for the industry. I may be wrong but i need some clarification >> about it. >> >> >> I just want to know that why smalltalk is not so popular as the other OOPs >> Languages and what is the future prospect of >> >> one if he/she is into Smalltalk development. >> >> Looking for some positive note so that it may give me some entho for working >> with Smalltalk. >> >> Thanks&Regards, >> >> Sourav Roy >> >> >> >> Get Yourself a cool, short @in.com Email ID now! >
Re: [Pharo-project] Timespan #intersection: yields wrong result
Stef, No, and it seems I have mixed up Chronology and Chronos. I just got an answer from Alan Lovejoy confirming that my snippet works correct in the Chronos implementation (which is not the standard date/time library). So, I'm still wondering why this is not the case in Chronology. I will definitely check out Chronos and Aconcagua now. Stupid me that I did not see that :-( Johan On 03 May 2011, at 22:51, Stéphane Ducasse wrote: > BTW johan did you also check aconcagua? > > > Stef > > On May 3, 2011, at 7:25 PM, Johan Brichau wrote: > >> Hi, >> >> I traced a bug when working with timespans to the following issue >> illustrated in the code snippet below. >> The last expression in the snippet yields false, although it should yield >> true (imho). >> >> |start end span| >> start :=DateAndTime now. >> end := start + 1 hour. >> span := Timespan starting: start ending: end. >> (span intersection: span) = span --> false >> >> I think that the intersection of a span with itself, should be itself. The >> origin of the problem is that Timespan>>intersection: creates a new timespan >> roughly as follows: >> >> Timespan starting: aBegin ending: self end. >> >> But Timespan>>end returns the end time of the timespan minus the >> clockprecision. As such, the intersecting span is a nanosecond shorter than >> the one we would expect. This eventually yields wrong results when working >> with timespans. >> >> The real question now is: should the implementation of >> Timespan>>intersection be changed -or- should Timespan>>end really return >> the (non-included) end time (that was passed when constructing it)? >> >> I sent this email to b...@chronos-st.org, but a discussion here probably >> will not hurt either. >> >> Best regards >> Johan Brichau > >
Re: [Pharo-project] Timespan #intersection: yields wrong result
On 03 May 2011, at 20:44, Brent Pinkney wrote: > I wrote this Chronology stuff, so I can assure you that the behaviour is > deliberate. You never want overlapping timespans. ever :) > > Let me know if you want some more details. Yes, please, because it's not making sense to me. I understand "overlapping timespans" as timespans that have a non-empty intersection, so I cannot follow that remark. The intersection of 2 timespans is implemented to be smaller (exactly one clockPrecision unit) than it really is? In the end, because I'm working with timespans in a scheduling application, I get funny gaps of a nanosecond between the timespans. Mind that I understand that timespans are left-closed right-open intervals. The point is that the "right end" is a nanosecond off after taking the intersection, imho. What is even funnier is that if you loop the script I sent, you eventually end up with an empty intersection... because it gets smaller all the time. So yes, I cannot understand that :-( Johan
[Pharo-project] Timespan #intersection: yields wrong result
Hi, I traced a bug when working with timespans to the following issue illustrated in the code snippet below. The last expression in the snippet yields false, although it should yield true (imho). |start end span| start :=DateAndTime now. end := start + 1 hour. span := Timespan starting: start ending: end. (span intersection: span) = span --> false I think that the intersection of a span with itself, should be itself. The origin of the problem is that Timespan>>intersection: creates a new timespan roughly as follows: Timespan starting: aBegin ending: self end. But Timespan>>end returns the end time of the timespan minus the clockprecision. As such, the intersecting span is a nanosecond shorter than the one we would expect. This eventually yields wrong results when working with timespans. The real question now is: should the implementation of Timespan>>intersection be changed -or- should Timespan>>end really return the (non-included) end time (that was passed when constructing it)? I sent this email to b...@chronos-st.org, but a discussion here probably will not hurt either. Best regards Johan Brichau
Re: [Pharo-project] add temp does not add the temp in 1.3 13179
On 03 May 2011, at 10:14, Mariano Martinez Peck wrote: > aha I didn't try that ;) > So...in 1.2.1 adding from a browser does work, but not from the debugger? > And in 1.3 none of them? I don't know about 1.3 but it's one of the things I started to notice about 1.2.1 this week. In the browser, it works fine.
Re: [Pharo-project] add temp does not add the temp in 1.3 13179
On 03 May 2011, at 10:04, Mariano Martinez Peck wrote: > On Tue, May 3, 2011 at 7:53 AM, Lukas Renggli wrote: > This is already broken in Pharo 1.2. > > In the official Pharo 1.2.1 it works correct. Nope. When adding a temp while in the debugger it does not add the temp either in Pharo1.2.1 Johan
Re: [Pharo-project] Hudson setup published?
Stephan, I think you refer to the tests that fail when run in a headless image? This is often because they test behavior that assumes an interactive UI Manager (i.e. which prompts the user). The solution lies in making the tests work with the NonInteractiveUIManager. Either adapting the test, or adapting the UI Manager. On 20 Apr 2011, at 07:58, Stephan Eggermont wrote: > Is the Hudson setup used to generate the Pharo images published? > Last friday there were some issues that were not reproducible with > the standard test-runner. > > Stephan >
[Pharo-project] Brussels Sprint: gathering number of attendes
Hi everyone. To make sure we have enough food and drinks for everyone. Please make sure to let us know you are coming. From previous emails, I have understood the following people are attending: - Steph - Marcus - Sven - Mariano - Craig Latta - Thomas Holzer - Andy - Johan Someone on here who is not attending? Someone not attending who is listed above? The parking access code will follow shortly. ps: I will bring some Faro beer this time then ;-) Johan
Re: [Pharo-project] Pharo sprint at Brussels Friday 15th of April
On 04 Apr 2011, at 11:45, Sven Van Caekenberghe wrote: > > On 04 Apr 2011, at 11:41, Johan Brichau wrote: > >> Place: Software Languages Lab, 10th floor of building F, Vrije Universiteit >> Brussel, Belgium > > And the timeframe ? 9:00 early enough for you? ;-) We can be there until 18:00.
Re: [Pharo-project] Pharo sprint at Brussels Friday 15th of April
Hi guys, Time flies... I had forgotten all about it ;-) So here is the info: Place: Software Languages Lab, 10th floor of building F, Vrije Universiteit Brussel, Belgium Directions: http://www.vub.ac.be/english/infoabout/campuses/index.html#etterbeek Map: http://www.vub.ac.be/english/infoabout/campuses/etterbeek.html In case you have trouble finding it, please phone Andy: +32 494 42 32 56 or Johan: +32 476 78 64 45 If you are coming by car, you will need a barcode to access the campus. I will send that in a following email. cheers Johan On 04 Apr 2011, at 09:21, Sven Van Caekenberghe wrote: > > On 02 Apr 2011, at 09:31, Stéphane Ducasse wrote: > >> Johan Brichau and Andy Kellens are organizing a sprint at VUB. >> Please let us know who will join. >> I will join > > That's an offer I can't refuse: so yes, I'll be joining too. > > What are the details, timeframe & place ?
Re: [Pharo-project] Loading GemTools in Pharo 1.1.1-dev
well... it only works with a VM up to version 4.2.2 everything beyond that ended up in a strange login error, indeed On 30 Mar 2011, at 18:19, Dale Henrichs wrote: > Yes I am suspicious that there are some os library mismatches involved as I > get an odd error during the login sequence and I haven't successfully > characterized the specific problem... > > I am glad to hear that some folks are not having trouble ... which only > deepens the mystery:) > > Dale
Re: [Pharo-project] Loading GemTools in Pharo 1.1.1-dev
Hi Veronica ;-) First update Metacello: ConfigurationOfMetacello project updateProject On 30 Mar 2011, at 15:42, Veronica Isabel Uquillas Gomez wrote: > Hi, > > I want to try GemStone. So I started loading GemTools in a Pharo image > 1.1.1-dev without success. > An error appears when loading Metacello Browser version #development. > After that I tried to load first MetacelloBrowser and then I got the same > error for OmniBrowser version #stable. > > What am I doing wrong? or do I need to use a different image? > > Regards, > Veronica
Re: [Pharo-project] Doing research with the iPad
On 03 Mar 2011, at 19:42, Stéphane Ducasse wrote: >> Can I throw my laptop for an ipad? Absolutely not. An iPad and a laptop are completely different devices. Besides, Pharo/Squeak runs slooow on the iPad Johan
Re: [Pharo-project] Url / HTTPSocket with https://
I am not certain if it works, but the Cryptography package has an implementation for an https client: http://www.squeaksource.com/Cryptography.html On 02 Mar 2011, at 08:16, laurent laffont wrote: > Hi, > > (Url absoluteFromText: 'https://www.google.com') retrieveContents > > or > > HTTPSocket httpGet:'https://www.google.com'. > > fail because they don't like https://. How can I get content on https:// ? > > > Laurent Laffont - @lolgzs > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/
Re: [Pharo-project] 2 days vs 2 day
+ 1 The method makes _no_ sense at all. On 26 Feb 2011, at 10:40, Edouard Poor wrote: > I've been thinking about it, and I think I can understand who this came > about, but silently giving a user the wrong answer if they mistype "days" or > write some code like "[ :n | n day ]" (I did this one) seems wrong. If "day" > should only answer with the singular value, than perhaps it should throw an > exception for any values other than -1 or 1. > > I'd actually prefer it just called days, and damn English grammar.
Re: [Pharo-project] Pharo 1.2 broken on Hudson due to XMLSupport changes
Otto, The changes you made to the configuration mean that the XMLParser packages are fetched from the gemsource repository for *all* platforms, and not only for GemStone. I don't think this should be the intention. The official code for the XMLParser for Pharo and Squeak are located in a squeaksource repository. On 24 Feb 2011, at 17:16, Otto Behrens wrote: >> It broke the Pharo 1.2 build on Hudson since 2 days: > > Sorry about that > >> Error: Could not resolve: XML-Parser [XML-Parser-OttoBehrens.125] in >> /builds/workspace/Pharo 1.2/Pharo-1.2/p > > This tells me that it can't find the file in the repository, specified > to be on gemsource, excerpt below. I am confident that I published the > XMLParser package on gemsource, but since I don't see it there, I have > doubts. I can try to get it published. Best would be if I can get > access to the XMLSupport project on squeaksource. > > package: 'XML-Parser' >with: [ >spec > > repository: 'http://seaside.gemstone.com/ss/XMLSupport';
Re: [Pharo-project] Pattern for reifying XML doc?
SIXX works very good to write/read objects, but it means you have to give up on your own xml schema. And it's almost to easy to use: sws := SixxWriteStream newFileNamed: aFileName. sws nextPut: (self objectsToExport). sws close. srs := SixxReadStream readOnlyFileNamed: (aFileName). objects := OrderedCollection new. [srs atEnd] whileFalse: [objects add: srs next]. srs close. On 21 Feb 2011, at 10:11, stephane ducasse wrote: > Hi guys > > I often encounter the following situation: I have an xmldoc and I want to > load it and get the corresponding objects. > Here is an example > > >Test2Cards > >All Is Dust >7 >7 >Tribal Sorcery — Eldrazi >Each player sacrifices all colored permanents he or she > controls. >mythic >1 >Jason Felix >STD >ELDRAZI > > >Kird Ape >G >1 >Tribal Sorcery — Eldrazi >get +1/+1 when you control >common >33 >Zork >STD >WORLDWAKE > > > > I have card and group. But I could have several kind of nodes. So I was > wondering if there are patterns to read in > and map that to objects. In the future I would like to have magritte like > type of first class instance variables that > perform i/o in xml or other formats because this is always the same. > > stef > > >
Re: [Pharo-project] Call for Pharo Support **important**
This is a good effort. I have the letter ready for submission. May I ask what the 'conditions for membership' are likely to be? By signing the letter, we acknowledge our intent to join the consortium 'subject to the conditions for membership'. I would at least like to know what these are ;-) Johan On 15 Feb 2011, at 15:49, Adrian Lienhard wrote: > BTW, the call is also online at http://pharo-project.org/community/consortium > > Adrian > > On Feb 15, 2011, at 14:02 , Stéphane Ducasse wrote: > >> Please distribute this message around >> >> >> Dear Pharoers >> >> We are pursuing an effort to bring Pharo to the next level: we will set up a >> consortium of pharo users and industrial partners. Our goal is to build a >> legal infrastructure that will be able to sustain the development of Pharo >> and improve its future. As an example, we would like to be able to collect >> funds (ways as to be determined - we foresee a membership model or moral >> license) to pay engineering tasks to be performed such as improving the >> virtual machine, network libraries, better JIT support. To make it short we >> would like to give a chance to our community to grow and structure itself so >> that Pharo can get stronger and that risk (truck factor) gets minimized. >> >> We are contacting you to know if your company/research group would be >> interested to support such effort. Showing such interest is strategically >> important for us and INRIA which could also support such effort. Attached is >> the letter of support that we will collect once signed and scanned ( >> stephane.duca...@inria.fr / faxed at: 00 33 (0)3 59 57 78 50) >> >> Thanks for your support >> >> The Pharo Board >> >> M. Denker, S. Ducasse, and A. Lienhard >> >> >> > >
Re: [Pharo-project] what do we do for OmniBrowser?
I want to use OB in 1.2 and that means I'm in for contributing as well. I just started trying 1.2-dev in the last couple of days and it seems not so many things are failing with OB? Am I wrong? 4 tests are failing in the image and there seems to be very few issues on the Pharo tracker about (most of them have a proposed fix). On 02 Feb 2011, at 15:57, Dmitri Zagidulin wrote: > (btw, I still > can't believe we as a community let SeasideTesting be broken in 1.2). Well, I just tested it in 1.2 for the first time and it works If something doesn't work for you, please send an email on the seaside mailinglist. I am actively using and maintaining SeasideTesting (whenever possible) and willing to help out if people experience problems. Mind that the external browser testing is a new feature that David included in his new version in VisualWorks but which I did not port to Pharo/Squeak (yet). However, the traditional simulated browser testing is working. We have over 300 tests in our application that use seaside testing. cheers, Johan
Re: [Pharo-project] faro ?
The brewery is on my road to work... and to Lille If people want me to bring some next friday... ;-) ps: Faro is a Lambic beer, which is the basis of a Geuze, _the_ unique Brussels beer... Johan On 19 Jan 2011, at 19:04, Sven Van Caekenberghe wrote: > > On 19 Jan 2011, at 18:43, Noury Bouraqadi wrote: > >> A student of mine sent me this picture :-) >> >>> >>> http://www.linternaute.com/homme/art-de-vivre/selection/selection-de-mousses-pour-le-printemps/image/faro-lindemans-21359.jpg >>> >> > > http://www.lindemans.be/start/faro/en > > Belgian Beer, of course. > > >
Re: [Pharo-project] Origins [poll] Summary
Johan Brichau | Dutch | Hoi | Belgium | Brussels area, Belgium On 08 Jan 2011, at 07:58, Miguel Cobá wrote: > This is the summary until now, kudos to the Argentinians as they are leading > the poll > > Name|Native Language|Greeting in native lang|Born country|Writing > from|Interests > > Germán Arduino|Spanish|Hola|Argentina|Sunchales, Argentina > Bernardo Contreras | Spanish | Hola | Argentina | Buenos Aires, Argentina | > guitar?, smalltalk, lisp, emacs, domain driven design > Mariano Martinez Peck | Spanish | Hola | Argentina | Douai, France | fly > fishing? > Gabriel Cotelli|Spanish|Hola|Argentina|Buenos Aires, Argentina| > Francisco Ortiz Peñaloza|Spanish|Hola|Argentina|Buenos Aires, Argentina| > Esteban Lorenzano | Spanish | Hola | Argentina | Buenos Aires, Argentina > Diogenes Moreira | Spanish | Hola | Argentina | Buenos Aires, Argentina > Guille Polito | Español | Hol | Argentina | Buenos Aires, Argentina | > useful and nice software, playing guitar, eating, teaching > > Alexandre Bergel | French | Bonjour | France | Chile | software quality, code > profiling, visualization, moose > Stéphane Ducasse | French | Salut | France | Lille > Alain Plantec|French|Bonjour|France|Brest, Brittany, France > Cédrick Béler|french|Salut|France|Tarbes (south west of France near > Lourdes)|Information System for industry / Companies, reasoning with > imperfect information, computers and high-tech, sports (volley-ball) > Laurent Laffont|French|Salut|France|Annecy, France|Musique, Lecture > Serge Stinckwich|French|Xin Chào|France|Hà Nội, Việt Nam > > Tony Fleig|English (well, American English)|Yo|USA|California, USA > Jimmie Houchin | English | Hello / Howdy| Carlsbad, New Mexico, USA | North > of Dallas, Texas, USA | Chile Head, Pepper Belly, writing a Financial > Investment app > Sean DeNigris | English | What's up | USA | New York, New York | > Hockey,surfing, reading > > Miguel Cobá|Spanish|Hola|Mexico|Mexico City,Mexico > > Cesar Rabak |Spanish/Portuguese/Italian|Hola/Olá/Ciao|Peru|São Paulo, SP - > Brazil > > Janko Mivšek | Slovenian | Zdravo | Slovenia | Ljubljana | web apps > > Benoit St-Jean | French | Salut | Canada | Montréal > > Sven Van Caekenberghe | Dutch | Hallo | Belgium | Hasselt, Belgium | Software > development using dynamic, interactive & object oriented languages, Smalltalk > & Lisp for Web & Server applications > > Noury Bouraqadi | Arabic | Salam | Morocco | Douai, France > > Stanislav Paskalev | Bulgarian | Zdravei | Bulgaria | Plovdiv, Bulgaria > > Tudor Girba | Romanian | Buna ziua | Romania | Berne, Switzerland > > Come on, keep the spice, em, info, flowing! > > Cheers > > > El mié, 05-01-2011 a las 21:37 -0200, csra...@bol.com.br escribió: >> Miguel, >> >> You rather create a wiki page (or edit the one Stef intends to put our >> pictures in a near future ;-) >> >> my 0.01999... >> >> -- >> Cesar Rabak >> >> Name|Native Language|Greeting in native lang|Born country|Writing from >> Cesar Rabak |Spanish/Portuguese/Italian|Hola/Olá/Ciao|Peru|São Paulo, SP - >> Brazil >> >> >> >> Em 05/01/2011 19:38, Miguel Cobá < miguel.c...@gmail.com > escreveu: >> It is a new year and I thought that it would be good to know from which >> part of the world each person in this list is (or was born), so we can >> get a better look at the diversity of the community. >> >> I start: >> >> Name|Native Language|Greeting in native lang|Born country|Writing from >> >> Miguel Cobá|Spanish|Hola|Mexico|Mexico City,Mexico >> >> Cheers > > -- > Miguel Cobá > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >
Re: [Pharo-project] Pharo sprint @ lille Friday 21 of January
I will be there On 09 Jan 2011, at 23:39, Stéphane Ducasse wrote: > pass the message around you that people should reply here so that we know > which organization to set up. > > On Jan 9, 2011, at 7:07 PM, Benjamin Van Ryseghem wrote: > >> I'll be there ^^ >> >> >> Ben >> >> 2011/1/9 Stéphane Ducasse >> Hi guys >> >> we will have a pharo sprint at Lille Friday 21 of January. If you want to >> join let us know that we organize for the food. >> The sprint will happen in our rooms at LIFL >> http://rmod.lille.inria.fr/web/pier/contactr/ >> >> Stef >> > >
Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (ph...@googlecode.com)
Andy agreed to pair program it with me, starting next week. Unless someone beats us to it ;-) On 09 Jan 2011, at 10:12, Stéphane Ducasse wrote: > + 1 > > does anybody want to implement this hovering excellent idea. > > > On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote: > >> And yes, the rule of thumb is that one reads the comments (or >> implementation) of a method to understand it, rather than (only) trying to >> guess it's semantics from its selector. >> We all got used to coding like that in Smalltalk. However, it's _just_ a >> rule of thumb that comments on top of the method body should document the >> method. Not all methods do it, and people coming from different languages >> and development environments are not immediately comfortable because they >> 'need to look at the implementation of an API to understand it'. So, I think >> there is something we can learn from other development environments: in >> XCode, for example, you can request the documentation of a method in a small >> 'hover window' by a + on the method name. I wonder if such a >> system in Smalltalk development environment would make documenting a method >> more important, and thus, force people to write and use it more >
Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (ph...@googlecode.com)
On 08 Jan 2011, at 23:07, Nicolas Cellier wrote:
> You mean something like:
>
> | collec |
> collec := #('foo' 'bar').
> shallowCopy := collec copy.
> self assert: collec first == shallowCopy first
>
> Well, yes those copies are shallow, but what's the difference between
> copy, copyFrom:to: first, first: etc... with this respect ?
I think Stephan intended to say that the return result of #first is not a copy
of (parts of) the receiver. #first is an accessor, not a copy message.
And yes, the rule of thumb is that one reads the comments (or implementation)
of a method to understand it, rather than (only) trying to guess it's semantics
from its selector.
We all got used to coding like that in Smalltalk. However, it's _just_ a rule
of thumb that comments on top of the method body should document the method.
Not all methods do it, and people coming from different languages and
development environments are not immediately comfortable because they 'need to
look at the implementation of an API to understand it'. So, I think there is
something we can learn from other development environments: in XCode, for
example, you can request the documentation of a method in a small 'hover
window' by a + on the method name. I wonder if such a system in
Smalltalk development environment would make documenting a method more
important, and thus, force people to write and use it more
Johan
Re: [Pharo-project] About preloaded packages
Hi Mariano, I'm not (really) concerned with image size. As a user of Pharo, I would expect that a Pharo dev image includes plenty of development tools and an easy way of loading external libraries (such as XML, Seaside, Glorp,). With the advent of metacello, we now have an easy loading mechanism for external libraries such that, to me, it's strange to see those libraries being deployed in a dev image of Pharo. Even a development image should be a base to start from. But I would like to see a lot of development tools pre-loaded. Pharo is already doing a good job at that, btw, unlike Visualworks where the syntax highlighter and many other useful development packages are add-ons. Explaining that syntax highlighting is an external library to load is something new students always were amazed about when I exposed them to Smalltalk... > 1) If you want to do business, XML is REALLY important. You like it or not (I > promise I hate XML). APIs, legacy systems, other systems, etc... Then again, database functionality is probably even more crucial than XML for any business app. My point is: if you need an XML library: you can load it. oh, and, not all business requires XML (lucky me ;-) > 2) We like it or not, the packages that are included in the dev images are > the most known, supported, maintained and tested. So... Glorp and Seaside too? I'm overstating but there are so many good and useful packages out there that is seems strange to include some and others not. > 3) XMLSupport has been asked in the mailing list several times Well, it's not because people ask that it's a good thing. This also applies to my own mail, btw :-)) (it's just my opinion) > Once we have that, and once that searching and installing Metacello projects > is really easy, I would start removing some packages from the dev image. I see your point, but XML is really easily installable already. But hey, I'm just expressing my opinion here and sorry that I did not react to any previous email (it's a bit too much for me). cheers, Johan
Re: [Pharo-project] About preloaded packages
On 07 Jan 2011, at 09:05, Stéphane Ducasse wrote: > I would really like that pharo-dev does not contain too many libraries pre > loaded (for example XMLSupport). > I would favor push metacello so that in one click people can load what they > want. +1
Re: [Pharo-project] Issue 3485 in pharo: VMMaker does not load on Pharo 1.2
wow let me take a step back here. First of all, *nothing* was ever imposed nor banned. As far as I'm concerned, SourceReference is a work in progress and the timestamp format that it parses has been reconstructed using archeology over different sources. Going back 2 spaces and parsing from there is what I did at first but that soon proved to be *not* correct. Please see formats 2,4 & 5. I did not invent those formats but found them in the sources. It seems there are different formats out there and the goal was to extract timestamps from as many methods as possible. I'll improve the way it extracts timestamps and make a graceful fallback. Johan On 30 Dec 2010, at 10:38, Stéphane Ducasse wrote: > Eliot > > johan is not that idiot. So far when I see what they built for their company > this is more the inverse. > He spent several days trying to figure out how to manage decently the source. > I will check with him what they did but they probably tried to extract > information from all the methods in the system. > > > changeStamp > "Answer a string to be pasted into source code to mark who changed it > and when." > ^ Author fullName , ' ' , Date today mmdd, ' ', > ((String streamContents: [:s | Time now print24: true on: s]) > copyFrom: 1 to: 5) > > Now how can I identify a comment from a person and and action? > Beginning until a space? > date end until a space? > > We can do that. It looks like a hack to me. > > People are building tools to **help** us but if we push on them unstructured > data then we push the shit on them. > Let's take a simple example: benjamin smart, young student rewrote the > recentMessage tools and the finder for fun. Now the > state of MethodReference and its clunky use made something trivial just a big > pain. I do not even talk about the change format > which need scanner invocation to distinguish between a class def and a doit. > So if we do not offer a good infrastructure we will be stuck for years with > old tools. Some people do not like change at all > but we value it for the better. > > > > > On Dec 30, 2010, at 12:47 AM, Eliot Miranda wrote: > >> >> >> On Wed, Dec 29, 2010 at 1:51 AM, Stéphane Ducasse >> wrote: >>> >>> The documented format is: >>> >>> Timestampstrings can be of the form: >>> . >>> >>> >>> >>> >>> >>> >>> >>> Says /who/? When I created all these timestamps to document a refactoring >>> change there was no documented restriction on timestamps I could see. Why >>> impose restrictions which have little value? Why needlessly break >>> compatibility? That timestamp *contains useful information*. Why ban it? >>> >>> If you *want* VMMaker to load in Pharo you need to ensure that Pharo >>> supports the timestamps *that exist* not the timestamps you want to impose >>> on the community. >> >> Eliot we do not impose anything to the community. Please do not bash us we >> have enough to do without that! >> >> Steph, /I'm/ not bashing. I got bashed. Suddenly the comments I'd put in >> VMMaker were to be banned by Pharo. Look, the timestamp syntax if any, is >> defined by Utilities class>>changeStamp, along with the implicit restriction >> that the changeStamp can't contain an exclamation point, or it'll break >> parsing. Utilities class>>changeStamp is essentially anything followed by >> date and time, because there are /no/ restrictions on what one sets the >> Author initials to be (some people use full name, some people use initials, >> some people use put other stuff in there, but it's free apart from the $!). >> So to parse date and time one has to start at the end of the timestamp, go >> back two spaces and parse from there (ooh, difficult ;) ). There's no need >> for anything else. Why make life difficult for the community by imposing >> syntax when none existed before? All you'll do is make work and frustrate >> people. Is Pharo about helping or hindering? I think it's about helping, >> but the above syntax restrictions don't feel like that. KISS, right? If >> you want to find the date or time in a timestamp start at the end, and leave >> the beginning free from interpretation. >> >> 2¢ >> >> >> Apparently the code was like that and people (may be johan) started to make >> sense out of it. >> >> Stef >> > >
[Pharo-project] socket deadlock using Cog VM
Hi, We are experiencing a deadlock in Socket>>waitForDataIfClosed: The problem occurs on Pharo11/Pharo12/Squeak41 only when using the Cog VM. In our particular case, the socket connects to a GOODS database and it started occurring with a growing amount of data (so longer connections, more data transfer). When you open a debugger on the deadlocked process and proceed the process, it will simply continue and finish without problems. We are using Cog VM of 4 october, downloaded from Eliot's website (VM.r2316/) Before I start isolating the problem and reproduce it without requiring GOODS (it's just an http socket anyway): Is anyone else experiencing similar issues here? Is there a fix in more recent versions? cheers Johan
Re: [Pharo-project] Parsing and navigating Html
SeasideTesting uses the XMLParser for parsing html files and has support for querying them. It's not complete but, for example, covers quite a lot of cases needed in testing, obviously On 04 Dec 2010, at 22:15, Sean P. DeNigris wrote: > > I recently got the following very detailed response on the Squeak list - > http://forum.world.st/HTML-parser-again-again-td3018595.html > > In addition to what's discussed there, I've been successfully using > PetitParser with/in lieu of HTML parsers for partial parsing. > > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Parsing-and-navigating-Html-tp3072743p3072777.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
Re: [Pharo-project] SimpleTraits - How can we have Traits/Mixins quickly?
On 29 Nov 2010, at 16:38, Peter van Rooijen wrote: > Now it seems that Traits have somehow not "made it" into > Pharo and I believe with you that it is a shame not to have it. there's no need to despair: traits *are* in Pharo ;-)
Re: [Pharo-project] About SourcedMethodReference
On 10 Nov 2010, at 10:14, Benjamin wrote: > The last version is in !.2, and I'm still working on killing MethodReference > references (I've done a ChangeSorter, I'm still playing with it, expecting > for explosions ^^ If you want to play with it too, just say it to me) Ok Ben, consider this a yell ;-) I can spend some time on this over the long weekend in Belgium. I'll just work myself back in from the code I can find online Johan
Re: [Pharo-project] About SourcedMethodReference
On 10 Nov 2010, at 12:14, Eliot Miranda wrote: > Why do you want to remove MethodReference? The work was initiated from Benjamin's work on a new browser for 'recent changes', which basically needs to manipulate source references. MethodReference is being used to this end in various parts of the system but it represents various different things: class comment reference, method source reference, class definition reference, etc.. In addition, it always represents a reference to the current source. To retrieve older versions of the source, you need to walk the changes stream yourself. Last but not least, various different tools are walking the changes file with different implementations. From that experience, the idea arose to create a sourcereference model that explicitly models the different source elements (methods, class comments, definitions, etc) and that has explicit timestamping. At the same time, we don't want to break existing tools and have embedded the exisiting MethodReference in that model. Johan
Re: [Pharo-project] About SourcedMethodReference
There is still a lot to be done, so I did not know the changes were already integrated ;-) But the subclassing construction is temporary to allow code to migrate to the new sourcereference framework. Benjamin: is the latest version in 1.2 or on pharotaskforce or ... ? On 10 Nov 2010, at 04:22, Benjamin wrote: > > On Nov 9, 2010, at 10:48 PM, Luc Fabresse wrote: > >> Hi all, >> >> When SourcedMethodReference have been introduced, some tests in >> SystemNavigationTest turned yellow. >> The tests are currently expecting a MethodReference. >> If I modify the tests to exepect a SourcedMethodReference, the problem is >> now on: >> >> SourcedMethodReference>>= >> ^self == aMethodReference. >> >> Why this has been redefined in SourcedMethodReference? > > It has been redefined becausea the end, we want to remove MethodReference, > and this is the default behavior for the method = > >> I think that the super class (MethodReference) implementation is >> semantically better. No? >> >> MethodReference>>= anotherMethodReference >> "Answer whether the receiver and the argument represent the >> same object." >> ^ self species == anotherMethodReference species >> and: [(self classSymbol = anotherMethodReference classSymbol) >> and: [(self classIsMeta = >> anotherMethodReference classIsMeta) >> and: [self methodSymbol = >> anotherMethodReference methodSymbol]]] >> #Luc > > This method doesn't answer what we expect anymore, because here, two > references (with different source) pointing on two versions of the same > method are evaluate as equal, and we do not want that. > > About tests, JB and I had wrote a fix, but we have lost it ... > But I will take a look at that asap > > > Thank you for your feedback > > > Ben > >
Re: [Pharo-project] Date time iso8601 format
When I evaluate: DateAndTime now printString -> '2010-11-07T20:42:26+01:00' On 07 Nov 2010, at 13:50, laurent laffont wrote: > The other way. For example > > DateAndTime now printISO8601 > > Laurent > > > On Sun, Nov 7, 2010 at 1:28 PM, Johan Brichau wrote: > Laurent, > > DateAndTime readFrom: '2008-02-10T12:00:00Z' readStream > > Does that yield what you want? > > cheers > Johan > > On 06 Nov 2010, at 15:07, laurent laffont wrote: > >> Hi, >> >> I cannot find which method to use to get a Date in iso 8601 format like >> '2008-02-10T12:00:00Z' ? >> >> >> Cheers, >> >> Laurent Laffont >> >> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >> Blog: http://magaloma.blogspot.com/ > >
Re: [Pharo-project] Date time iso8601 format
Laurent, DateAndTime readFrom: '2008-02-10T12:00:00Z' readStream Does that yield what you want? cheers Johan On 06 Nov 2010, at 15:07, laurent laffont wrote: > Hi, > > I cannot find which method to use to get a Date in iso 8601 format like > '2008-02-10T12:00:00Z' ? > > > Cheers, > > Laurent Laffont > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/
Re: [Pharo-project] XML package is barking at load time
Hi Stef, This works without dog sounds: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfXMLSupport'; load. ConfigurationOfXMLSupport load On 31 Oct 2010, at 10:55, stephane ducasse wrote: > Gofer new > squeaksource: 'XMLSupport'; > package: 'XML-Parser'; load. > > raise error because of tests not present. > > Did I do something wrong?
Re: [Pharo-project] Smells looking at collections
On 24 Oct 2010, at 20:06, Levente Uzonyi wrote: >> PolyMorphic also uses traits. > > Where can I find it? Sorry, I meant Polymorph. The PolyMorph-Widgets category in any Pharo image has them: TEasilyThemed, TEnableInHalo (or something like that). >> There are non-core projects that also use them, for example WebTester. > > I don't see any trait in the latest version, though I used SqueakSource's web > interface. There's just one (WtTClickable) right now. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Smells looking at collections
On 24 Oct 2010, at 08:42, Stéphane Ducasse wrote: >> Well, Traits are in Squeak since 2006, IIRC they were available a few years >> earlier. So in the last X (at least 4) years the only good candidate to >> become a Trait was Magnitude. PolyMorphic also uses traits. There are non-core projects that also use them, for example WebTester. I can also name several occassions in the development of our application, where we considered using traits to avoid code duplication. The only reason we didn't was because of a need for portability to GS. But if I understood correctly, it's quite possible that GS will support them in the future. Traits are being added to many other languages as well (e.g. traitsjs.org). It would be a shame to remove them from Squeak/Pharo Smalltalk now. just my 2 cents, Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Looking for real-world Magma application
Hi Igor, I guess that you are referring to us ;-) We indeed switched from Magma to GOODS and now to Gemstone, mainly because of performance issues. To remain db-independent, we have created a database abstraction layer that can be used with any of the aforementioned databases. We are currently preparing to open-source the generic part and we can send you our specific Magma specialization with representative queries made by our application. We should be able to get that to you asap! Johan On 21 Oct 2010, at 08:33, Igor Stasenko wrote: > Hello all, > sorry for cross-posting. :) > > I'd like to ask you, if anyone could share either an image or > installation with application, > which using Magma OODB. > I'd like to use it & test how changing different aspects of Magma > internals could affect the performance. > > There's many tricks, which is known by Chris how to speed it up by > cleverly fine-tuning various Magma options, > like read strategy etc. > But what i'd like is to see, is some setup, used by people, and by > taking it, see how it could make run faster, > without changing an application code. > > I remember, someone gave a talk @ ESUG, that they were using Magma for > their application, > but then forced to switch to another DB layer, because they had bad > performance issues. > It would be good, if you could give me the code, so i can run it and > see if things could be improved. > Its not a problem, if code is not open-source, we could sign an NDA, > if this is necessary. > > I need something real, simply because benchmarks sometimes not > representative. :) > > -- > Best regards, > Igor Stasenko AKA sig. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] pharo sprint at lille
Did you guys move?
On 28 Sep 2010, at 21:42, Marcus Denker wrote:
>
> On Sep 28, 2010, at 9:31 PM, Mariano Martinez Peck wrote:
>
>> Does someone know how to go there? which metro station is better? google
>> map ?
>>
> It's in the main INRIA building.
>
> http://www.inria.fr/lille/CRI-en/Howtogetthere
>
> This is just "behind" the university campus in a science/industry campus
> ("Parc Scientifique de la Haute Borne")
>
> Best station is "4 Cantons" (the last one).
>
> From the station, walk along the tracks of the metro (the one where the metro
> car goes empty) until the big street. The go to the left along the street.
> After the CNRS IRCICA building you will see the INRIA building. (see map).
>
>> what time does it start?
>>
>
> I guess someone will be there at 9:00... or even earlier if needed.
>
>> thanks
>>
>> mariano
>>
>>
>> 2010/9/28 stephane ducasse
>> Hi guys
>>
>> I reserved a nice room for the sprint it is in the inria building. salle du
>> conseil.
>> We will code like crazy :)
>>
>> Stef
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Marcus Denker -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ('a' == 'a') == true ?
On 28 Sep 2010, at 18:00, Eliot Miranda wrote: > I think it's orthogonal to immutability. Non-immutable literals are "just > plain wrong" (actually unsafe). The optimization is confusing and unexpected > to the inexperienced. But I emphatically agree with the last part; it's not > a particularly useful optimization. Of course, you are right: non-immutable literals are unsafe. However, when you know what you are doing and you are 'mutating' a literal in your code, I think it's surprising that the mutation also happens to what seems to be another literal in the same code (because they are written in different locations in the same method body), just because they happen to be equal. Admittedly, it's not a common issue and mutating literals might sound like dirty code (it probably is in 99% of the cases) but the flexibility also enables powerful things. I have, for example, used that in the implementation of the compiled methods for proxy java classes in JavaConnect. Anyway, I appreciate the discussion! Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ('a' == 'a') == true ?
Perhaps the discussion I wanted to raise is not about the use of '==' but about the fact that equal string literals in the same method body are optimized to be the same object. Without immutability, such optimization is just plain wrong. In addition, it does not even seem to be a particularly useful optimization. The use of '==' in the exercise is exactly about the reflective semantics, btw. Johan On 28 Sep 2010, at 10:05, Niko Schwarz wrote: > But that's the point, there should be no business semantics to '=='. > Only reflective semantics. The reflective semantics are ok. > > Niko > > On Mon, Sep 27, 2010 at 11:51 AM, Johan Brichau wrote: >> >> On 27 Sep 2010, at 11:28, Igor Stasenko wrote: >> >>> On 27 September 2010 11:54, Johan Brichau wrote: >>>> >>>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >>>> >>>>>> Am I wrong? >>>>> >>>>> Yes, almost always one should probably use #= instead of #==. >>>> >>>> I will add that to the exercise :-) >>>> The exercise actually makes students aware of the difference between >>>> strings and symbols (which should be pointer-equal) >>>> >>> >>> I think you can avoid using 'equal' word when describing a #== comparison. >>> It can be explained as 'test whether comparands are same object or not' >>> while #= is test whether two objects equal or not. >> >> Yes, this is exactly what the exercise is doing. >> I want them to be aware that equal _symbols_ are the same objects, but that >> equal _strings_ are not, which is why I let them evaluate: >> >> a := #foobar. >> b := #foobar. >> a == b. >> >> a := 'foobar'. >> b := 'foobar'. >> a == b >> >> The problem is that evaluating the second snippet also yields true in >> Pharo/Squeak, so I cannot illustrate it using these snippets (which works >> fine in Visualworks, btw). >> >> Yes, this is a compiler optimization and, yes, people should use #= instead >> of #== normally. But imho the optimization yields a wrong semantics, which >> is why I posted the email. >> >> I have absolutely no clue if it can be changed (I am not familiar with the >> compiler implementation *at all*), but I would be happy to look over the >> shoulder of an experienced compiler hacker during the next sprint to learn >> ;-) >> >> cheers >> Johan >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ('a' == 'a') == true ?
On 27 Sep 2010, at 14:37, Schwab,Wilhelm K wrote: > "Works fine" is a value judgment that can cut both ways: one could also argue > that VW lacks a useful optimization of literals. Non-literal strings should > do what you want. I wonder how useful the optimization is, actually. Probably not many (if any) methods will use the same literal multiple times and count on the compiler to optimize them into the same literal. Inversely, I have never run into that issue myself either, until I was just testing those little snippets for the students. Or... at least, I think I never have :-) Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ('a' == 'a') == true ?
On 27 Sep 2010, at 20:01, Sean P. DeNigris wrote: > Where did you get that Strings are guaranteed not to be 1 per value? where did I say that? Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ('a' == 'a') == true ?
On 27 Sep 2010, at 12:34, Igor Stasenko wrote: > Why waiting for sprint? I guess I thought the solution was more intricate than that :-) > Implement > > String>>literalEqueal: anObject > > ^ self == anObject > > and then you have > 'aaa' == 'aaa' -> false Thanks for pointing that out to me, Igor! I created an issue for it (3006) and will see later this week if it is a good idea to change the implementation of #literalEqual: to be less liberal. Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ('a' == 'a') == true ?
On 27 Sep 2010, at 11:28, Igor Stasenko wrote: > On 27 September 2010 11:54, Johan Brichau wrote: >> >> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >> >>>> Am I wrong? >>> >>> Yes, almost always one should probably use #= instead of #==. >> >> I will add that to the exercise :-) >> The exercise actually makes students aware of the difference between strings >> and symbols (which should be pointer-equal) >> > > I think you can avoid using 'equal' word when describing a #== comparison. > It can be explained as 'test whether comparands are same object or not' > while #= is test whether two objects equal or not. Yes, this is exactly what the exercise is doing. I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: a := #foobar. b := #foobar. a == b. a := 'foobar'. b := 'foobar'. a == b The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) cheers Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ('a' == 'a') == true ?
On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >> Am I wrong? > > Yes, almost always one should probably use #= instead of #==. I will add that to the exercise :-) The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] ('a' == 'a') == true ?
I convinced the teacher who will be taking over my Smalltalk courses at UCLouvain (starting this week) to use Pharo :-) One of the introductory exercises in these courses shows the difference between '==' and '='. However, in Pharo (&Squeak) the following goes wrong imho: 'a' == 'a' -> true $a asString == $a asString -> false It seems that when you evaluate the expression, the (semantically identical) strings are represented as the same literal in the compiled block. For example, try to evaluate the following code by evaluating each statement in a separate doit. Then do it again as a single block... |a b| a := 'a'. b := 'a'. a == b inspect Do I make it an issue? Is there already an issue? (did not find one) Am I wrong? Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiler throws error in Gemstone, not in Pharo
What's the dot doing after 'aSelector' ? :-) it's an empty statement -> gs parser does not allow that btw, I think this is a rule in code critic, so if you launch that, you will get all these problems before trying to load them into GS On 13 Sep 2010, at 13:55, Stéphane Ducasse wrote: > Yes but what is wrong on gemstone. > > Stef > > >> Dear list, >> >> while testing between Pharo and Gemstone I've noticed that Pharo allows >> following code, while Gemstone does not. >> >> renderSelectorAndReturnBrushForSelector: aSelector. >>^canvas textInput >>id: (self idForSelector: aSelector); >>value: (self inputValueForSelector: aSelector); >>script: (canvas jQuery new datepicker); >>yourself >> >> The error is that in the message definition: >> renderSelectorAndReturnBrushForSelector: aSelector. there is a dot on the >> end. >> >> This seems like an error in the Pharo compiler ? or not? >> >> Kind Regards, >> >> Bart >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo sprint Friday 1 of October @ Lille
You can count me in. Johan (from a sunny place :-) On 06 Sep 2010, at 15:27, Stéphane Ducasse wrote: > Hi guys > > we want to do a pharo sprint the friday 1st of October. > > Stef > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] return character magic?
so what did you do? I see that the file got removed... I will submit a bug issue for that with the file attached. The *real* problem is that you cannot remove it either! It does _not_ want to go away! On 30 Aug 2010, at 20:31, Stéphane Ducasse wrote: > A while ago I got the same with _ > > Stef > > On Aug 30, 2010, at 8:28 PM, Johan Brichau wrote: > >> Hi all, >> >> Just last week, I had a very strange phenomenon in my Pharo image: the >> return character (^) was changed by an up arrow (see screenshot below). >> I was not really able to reproduce the 'problem' but now we got a repeatable >> one: >> >> Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary >> addFileAt: ' ...'): you will see that the method will also have such a >> return char. >> >> What is going on? :-) >> >> I'm on Mac, using Pharo 1.1. >> >> cheers, >> Johan >> >> >> >> >> >> >> >> A MIME attachment of type was removed here >> by a drop-attachments-by-name filter rule on the host >> . >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] return character magic?
Hi all, Just last week, I had a very strange phenomenon in my Pharo image: the return character (^) was changed by an up arrow (see screenshot below). I was not really able to reproduce the 'problem' but now we got a repeatable one: Just load the attached js file in a Seaside WAFilelibrary (WAFilelibrary addFileAt: ' ...'): you will see that the method will also have such a return char. What is going on? :-) I'm on Mac, using Pharo 1.1. cheers, Johan <> A MIME attachment of type was removed here by a drop-attachments-by-name filter rule on the host . ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ifEmpty:ifNotEmpty (was: WebClient-Core port to Pharo 1.1 final)
On 30 Aug 2010, at 15:35, jaayer wrote: > On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi wrote > >> I don't like the "magical" #asString, but you should discuss it with >> Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in >> the WebClient-Pharo package (and in Squeak), and I think it's better than >> nil. > > I opened a ticked on this a few weeks back: > http://code.google.com/p/pharo/issues/detail?id=2794 > > The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should > be adopted. heu... I evaluated the following in a pharo1.1-dev and 1.2-core: (#(foo) ifEmpty:[#bar]) -> returns #(foo) (#() ifNotEmpty:[#bar]) -> returns #() This seems to do what you propose? Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Hi Andreas, I am not a lawyer but as far as I understand this topic, no license means nobody can use the code at all, which contradicts the fact of having it in a public repository (and you being perfectly happy of people using it). Can you please clarify the license situation of those projects? Best regards, Johan On 30 Aug 2010, at 00:00, Andreas Raab wrote: > As you can see, when I mean to put code under the MIT license, I try to state > that by including a copy of the license on the front page of the repository > as well as setting the license field. Contrary to, for example, the following > repositories: > > http://www.squeaksource.com/ar.html > http://www.squeaksource.com/SqueakSSL.html > http://www.squeaksource.com/WebClient.html > > which are not (or not yet) under MIT. Obviously, I'm trying to be as clear as > possible on these matters, which is why I was pointing out that your > repository incorrectly claims that the version of WebClient in it is LGPLv2. > I'm surprised (and shocked) that apparently nobody in Pharo even tries to > find out what the license status for WebClient is. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 'foo' asTime
err, yes it actually still is this one: http://code.google.com/p/pharo/issues/detail?id=2854 :-) On 27 Aug 2010, at 10:16, Stéphane Ducasse wrote: > johan > > thanks > Now get the reflex to create an issue else we get flooded of information. > I will integrate them now. > > Stef > > On Aug 26, 2010, at 2:34 PM, Johan Brichau wrote: > >> >> On 26 Aug 2010, at 04:47, Guillermo Polito wrote: >> >>> And now, because of fixing Integer>>readFrom:, 'foo' asTime throws an >>> exception and we all are a bit happier :D. >> >> Indeed. thanks. >> And just to make sure that we keep being happy, I added some unit tests to >> verify that in the KernelTests package ;-) >> >> Johan >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] String to Number conversion
On 26 Aug 2010, at 15:09, Guillermo Polito wrote: > Number readFrom: '3foo'. --> exception > Number readFrom: '3foo' readStream --> 3 They both return 3 in my image. The comment of #readFrom: also says so that that is the expected behavior. But I'm not sure this is what we want. > String>>asNumber should fail :). agreed. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] String to Number conversion
On 25 Aug 2010, at 09:26, Stéphane Ducasse wrote: >> Did you mean to let the dirty stuff to #squeezeOutNumber and throw the error >> in the #readFrom:? > > Yes. Now we should identify user of readFrom: that in fact are expecting > squeezeOutNumber and fix them. Well, it seems that the current readFrom: only requires the string to _start_ with a valid format. This means that: '3foo' asInteger = 3 Should we not fail here too? What are the opinions? Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
