August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SerialPort - named ports on Linux

by David T. Lewis

Yes. On Mon, Aug 30, 2010 at 11:38:09PM -0400, Schwab,Wilhelm K wrote: > Are the VM changes you mention the ones that exist now in the Linux VM? > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Serge Stinckwich [serge.stinckwich(a)gmail.com] > Sent: Monday, August 30, 2010 8:16 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] SerialPort - named ports on Linux > > To be tested : http://code.google.com/p/pharo/issues/detail?id=1057 > > On Tue, Aug 31, 2010 at 3:24 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > > Hello all, > > > > I recalled seeing mention of the Linux vm's now supporting named ports, and I found the code for that, at least in the vm. My understanding gets fuzzy as we enter the plugin and primitives. At a minimum, there are a few ByName methods to be added, and Squeak 4.1 contains open and close methods that test on type (int vs. string) to open or close by name or not as appropriate. > > > > Is this as simple as gathering the changes and adding them to Pharo, or does it require VMMaker magic? > > > > Bill > >

Aug. 31, 2010

Re: [Pharo-project] What are you using to write reports?

by Schwab,Wilhelm K

Tab-delimited text is very useful; I tend to see the world in terms of R (http://cran.r-project.org/) data frames, even when I do not plan to involve R. HTML makes a nice way to scroll through data. As for connecting with OpenOffice or (I can't say it<g>), I find LaTeX to be much nicer to use. It has a steep learning curve, but the view from near the top is pretty good. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Friedrich Dominicus [frido(a)q-software-solutions.de] Sent: Tuesday, August 31, 2010 2:13 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] What are you using to write reports? I'm working slowly through Seaside, Aida, Pharo etc. I just wonder what you are using to make "usable" reports. (Be it in electronical form or printed). A related question, how does you interface e.g to let's say OpenOffice or maybe MS Office? Thanks for suggestions. Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 31, 2010

Re: [Pharo-project] About the icons

by Henrik Johansen

For completeness when it comes to resources, I also have a port of the Assets package found in VisualWorks :) (Not performing very well without the once caching not working though) Cheers, Henry On Aug 31, 2010, at 10:38 35AM, Fernando olivero wrote: > Regarding the icons, i would like to spend some time during ESUG ( or the spring) merging what i have in Gaucho. > > Based on the previous work in MenuIcons and ThemeIcons, i've created an icon family importer, where all the icon contents are stored as methods in the corresponding subclass of GMIconFamily. > > A brief introduction, > > Object subclass: #GMIconFamily > instanceVariableNames: 'iconsGroups aliases' > classVariableNames: '' > poolDictionaries: '' > category: 'GauchoGUI-Morphic-ImagesAndIcons' > > > Where each GMIconFamily has the corresponding IconFamilyBuilder, that imports the external files from icon specs. > > IconsFamilyBuilder>>build > | specs secs | > specs := self iconsSpecs . > specs do:[:each| each resourcesFolderName: self resourcesFolderName ]. > ^ GMIconFamily createFamilyNamed: self iconFamilyName specs: specs . > > > For example, > > IconsFamilyBuilder subclass: #GauchoIconsBuilder > > GauchoIconsBuilder>>iconsSpecs > ^ self definedInSpecs , self bugSpecs, self accessorsSpec, .... > > GauchoIconsBuilder>>build . > > Will produce a bunch of methods in the GMIconFamiliyGaucho, that will hold the contents and provide access to the icons ( and also act as a form cache) > > then you can do > > icon := IconMorph named: 'apply' size: 16 familyNamed: 'gaucho'. > > I think that it wouldn't be hard to integrate this into Pharo1.2, to have a standardized manner of requesting icons, managing the forms, and easily importing external icon-families. I would be willing to work on this during the sprint. > > Fernando > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 31, 2010

Re: [Pharo-project] matchesRegex: multiline

by Nick Ager

On 31 August 2010 10:19, Lukas Renggli <renggli(a)gmail.com> wrote: > Looks like your version is very old, because the change-log in > RxParser class>>#b:whatsNewInThisRelease says: > > VERSION 1.1a (May 2001) > > 1. Support for keeping track of multiple subexpressions. > 2. Dot (.) matches anything but NUL character, as it should per POSIX > spec. > 3. Some bug fixes. > > Thanks Lukas I've filed a Gemstone bug: http://code.google.com/p/glassdb/issues/detail?id=166

Aug. 31, 2010

Re: [Pharo-project] matchesRegex: multiline

by Lukas Renggli

Looks like your version is very old, because the change-log in RxParser class>>#b:whatsNewInThisRelease says: VERSION 1.1a (May 2001) 1. Support for keeping track of multiple subexpressions. 2. Dot (.) matches anything but NUL character, as it should per POSIX spec. 3. Some bug fixes. Pharo contains the latest version available: VERSION 1.3.1 (September 2008) Additionally the version in Pharo includes an uncountable number of bug-fixes related to regular expressions that would cause infinite recursion, repeated matches, skipped matches, invalid empty matches, misaligned replacements, etc. Unfortunately these changes were not back-ported into the official VisualWorks version, as I never heard back from Vassily. Lukas 2010/8/31 Nick Ager <nick.ager(a)gmail.com>: >> Is there a way to allow the regex '.' (dot) to match line break >> characters: >> 'hello regex' matchesRegex: '.*regex' Â Â "true" >> 'hello >> regex' matchesRegex: '.*regex' Â Â "false" > >> >> In my image the second expression returns true as well. >> >> In fact the '.' (dot) matches anything but the null character (see >> >>#syntaxAny). > > Thanks - I shouldn't make assumptions - it matches in Pharo but not in > Gemstone - I assumed the implementations would beÂ identical. > As you say the culprit isÂ RxMatcher>>#syntaxAny > In Pharo: > RxMatcher>>#syntaxAny > ^RxmPredicate new > predicate: [:char | char asInteger ~= 0] > > In Gemstone: > RxMatcher>>#syntaxAny > ^RxmPredicate new > predicate: [:char | (Cr = char or: [Lf = char]) not] > Nick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Aug. 31, 2010

Re: [Pharo-project] matchesRegex: multiline

by Nick Ager

> Is there a way to allow the regex '.' (dot) to match line break characters: > 'hello regex' matchesRegex: '.*regex' "true" > 'hello > regex' matchesRegex: '.*regex' "false" > In my image the second expression returns true as well. > > In fact the '.' (dot) matches anything but the null character (see > RxMatcher>>#syntaxAny). Thanks - I shouldn't make assumptions - it matches in Pharo but not in Gemstone - I assumed the implementations would be identical. As you say the culprit is RxMatcher>>#syntaxAny In Pharo: RxMatcher>>#syntaxAny ^RxmPredicate new predicate: [:char | char asInteger ~= 0] In Gemstone: RxMatcher>>#syntaxAny ^RxmPredicate new predicate: [:char | (Cr = char or: [Lf = char]) not] Nick

Aug. 31, 2010

[Pharo-project] About the icons

by Fernando olivero

Regarding the icons, i would like to spend some time during ESUG ( or the spring) merging what i have in Gaucho. Based on the previous work in MenuIcons and ThemeIcons, i've created an icon family importer, where all the icon contents are stored as methods in the corresponding subclass of GMIconFamily. A brief introduction, Object subclass: #GMIconFamily instanceVariableNames: 'iconsGroups aliases' classVariableNames: '' poolDictionaries: '' category: 'GauchoGUI-Morphic-ImagesAndIcons' Where each GMIconFamily has the corresponding IconFamilyBuilder, that imports the external files from icon specs. IconsFamilyBuilder>>build | specs secs | specs := self iconsSpecs . specs do:[:each| each resourcesFolderName: self resourcesFolderName ]. ^ GMIconFamily createFamilyNamed: self iconFamilyName specs: specs . For example, IconsFamilyBuilder subclass: #GauchoIconsBuilder GauchoIconsBuilder>>iconsSpecs ^ self definedInSpecs , self bugSpecs, self accessorsSpec, .... GauchoIconsBuilder>>build . Will produce a bunch of methods in the GMIconFamiliyGaucho, that will hold the contents and provide access to the icons ( and also act as a form cache) then you can do icon := IconMorph named: 'apply' size: 16 familyNamed: 'gaucho'. I think that it wouldn't be hard to integrate this into Pharo1.2, to have a standardized manner of requesting icons, managing the forms, and easily importing external icon-families. I would be willing to work on this during the sprint. Fernando

Aug. 31, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Julian Fitzell

2010/8/31 Levente Uzonyi <leves(a)elte.hu>: > On Mon, 30 Aug 2010, Miguel Enrique CobÃ¡ MartÃnez wrote:> > > "You must be kidding. The freedom to fork is a essential right of open > > source software: > > http://news.cnet.com/8301-13505_3-10379280-16.html > > > > http://asay.blogspot.com/2006/10/wither-right-to-fork.html > > > > http://www.gnu.org/philosophy/free-sw.html > > http://www.opensource.org/docs/osd > > http://www.opensource.org/node/357 > > > > period." > > If you agree with OSI. Right. People always get into this argument. OSI has a definition of "Open Source" that is based on a moral position of having certain "freedoms" with the code. Legally, however, there is no such definition. When you write code, you (or your employer) own the code and you (or your employer) can release it under more or less any licenseâand with any restrictionsâyou desire. If I wanted, I could release code with the restriction that you can only use it on Wednesday! The right to create "derivative works"âobviously a significant component of forkingâis restricted by copyright law unless the creator explicitly grants that right to you. So you're perfectly free to say that WebClient is not "Open Source" if you wish; but you don't obtain specific rights just because the source is open. Your rights are entirely determined by your license with the creator(s). That's all I'll contribute to this discussion for the moment. We're working with intellectual property lawyers to prepare our ESUG talk on open source licensing; hopefully we'll be able to touch on some of this then and have some useful resources for the community as an output. Julian

Aug. 31, 2010

Re: [Pharo-project] problems with 12119 and 12120

by StÃ©phane Ducasse

HI guys to lower my stress I removed from the update stream the items related to my MethodReference changes. so please update from 12016 Benjamin I will try to find what is the problem. Stef On Aug 31, 2010, at 9:50 AM, StÃ©phane Ducasse wrote: > I was trying to clean a bit MethodReference and now I broke the merge in Monticello. > Now I get all the method with revision changed > > So what do we do? > > The changes were to help the integration of the new recentMessages changes > > 1- rollback because I do not have the time to dive into this part of the system. > We need a better and cleaner infrastructure with a real declarative code model and not a hack like methodReference and tweak it to get > comments and class definition on it. I hate that we have so lousy and brittle foundation > > 2- let it and try to understand why it breaks. But I have no time (now this stuff will stay in my mind until I check -grgrg). > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 31, 2010

Re: [Pharo-project] this style looks cool

by Tudor Girba

Hi, The simplest way to learn what the icon is saying is to just spawn the hierarchy view of that class, and the top most class that has the same icon is the one that the icon is supposed to be representing :). Cheers, Doru On 31 Aug 2010, at 10:05, Geert Claes wrote: > > > Tudor Girba wrote: >> >> ... >> >> Some of the icons that you see are shipped with Seaside. The blueish >> bubble denotes an announcement and is already present in Pharo. >> >> ... >> > > I like it too. Regarding the icons, is there somewhere a > description of all > the icons used as some are more self-explanatory than others? > -- > View this message in context: http://forum.world.st/this-style-looks-cool-tp2399247p2401191.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "We are all great at making mistakes."

Aug. 31, 2010