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

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

by StÃ©phane Ducasse

so now we understand why Pharo design is crap :) Sorry I could resist.... It would be nice if we were a bit more adults. What is strange is that some people catalyze communication problems (me included) but we should live with that. I added your bench to the issue too. Stef On Aug 31, 2010, at 12:34 AM, Levente Uzonyi wrote: > And another with "SmallDoc": > > smallDoc := ByteString new: 20 streamContents: [ :stream | > 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc squeakToUtf8 ] ] timeToRun ]. > "===> #(15 15 15 15 15)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. > "===> #(34 34 34 35 32)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. > "===> #(1256 1258 1259 1260 1260)" > > smallDoc := ByteString new: 20 streamContents: [ :stream | > 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. > smallDoc at: 10 put: (Character value: 129). > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc squeakToUtf8 ] ] timeToRun ]. > "===> #(115 112 112 113 112)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. > "===> #(157 125 124 126 125)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. > "===> #(1416 1419 1419 1429 1428)"

Aug. 31, 2010

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

by StÃ©phane Ducasse

thanks added to http://code.google.com/p/pharo/issues/detail?id=2885 Stef On Aug 31, 2010, at 12:22 AM, Levente Uzonyi wrote: > > In Squeak(CogVM): > "7-bit ByteString" > mediumDoc := ByteString new: 4096 streamContents: [ :stream | > 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > mediumDoc squeakToUtf8 ] ] timeToRun ]. > "===> #(344 345 344 347 344)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. > "===> #(404 373 375 374 374)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. > "===> #(1443 1440 1438 1443 1445)" > > "7-bit ByteString with a single 8-bit character" > mediumDoc := ByteString new: 4096 streamContents: [ :stream | > 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. > mediumDoc at: 2048 put: (Character value: 128). > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > mediumDoc squeakToUtf8 ] ] timeToRun ]. > "===> #(1262 1246 1249 1250 1249)." > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. > "===> #(1261 1256 1264 1260 1258)" > (1 to: 5) collect: [ :run | > [ 1 to: 100000 do: [ :ix | > mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. > "===> #(2591 2567 2538 2543 2582) Not neglible (~0.5 speed)" > > "8-bit ByteStrings (only 1000 conversion/test)" > mediumDoc := ByteString new: 4096 streamContents: [ :stream | > 4096 timesRepeat: [ stream nextPut: (Character value: 256 atRandom - 1) ] ]. > (1 to: 5) collect: [ :run | > [ 1 to: 1000 do: [ :ix | > mediumDoc squeakToUtf8 ] ] timeToRun ]. > "===> #(627 618 618 622 618)" > (1 to: 5) collect: [ :run | > [ 1 to: 1000 do: [ :ix | > mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. > "===> #(648 621 620 621 622)" > (1 to: 5) collect: [ :run | > [ 1 to: 1000 do: [ :ix | > mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. > "===> #(676 653 650 658 648)" > > "WideStrings" > mediumDoc := String new: 4096 streamContents: [ :stream | > 4096 timesRepeat: [ stream nextPut: (Character value: (1<<22) atRandom - 1) ] ]. > (1 to: 5) collect: [ :run | > [ 1 to: 1000 do: [ :ix | > mediumDoc squeakToUtf8 ] ] timeToRun ]. > "===> #(632 635 633 632 633)" > (1 to: 5) collect: [ :run | > [ 1 to: 1000 do: [ :ix | > mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. > "===> #(693 625 625 626 625)" > (1 to: 5) collect: [ :run | > [ 1 to: 1000 do: [ :ix | > mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. > "===> #(644 637 640 640 638)" > > > So, for 7-bit ByteStrings (optionally with few 8-bit characters), it does make a difference to use #squeakToUtf8, for 8-bit ByteStrings and WideStrings it doesn't really matter.

Aug. 31, 2010

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

by Andreas Raab

Hi - Thanks everyone for the reasoned and civil responses. It is good to see that we can have a disagreement without getting overly personal. Unfortunately, it seems that I'm effectively offered a no-win alternative here; I do not see how any of the discussed alternatives would help me achieve my goals. I will have to think about where to take things from here. If anyone has ideas, please let me know. Cheers, - Andreas On 8/30/2010 12:57 PM, Nicolas Cellier wrote: > Hi Pharoers, > I'm happy to read mail from Torsten, Igor and Miguel, thank you guys > that's constructive. > Andreas expressed his point very well, and i don't think it is > hostile, maybe a bit sarcastic or disenchanted, but overall he keeps > the door opened. > The first thing to do is to cool down, relax and think. > The second thing to do is engaging discussion with Andreas. > > Of course, the license is of prime importance, not having a license is > a showstopper. > If license is too restrictive then Andreas will probably fail to reach > his goals... > There will be de facto full rewrite rather than forks, but the net > result will be the same: failure to share packages/libraries. > > That's why I personnally don't find Andreas defensive position a good strategy. > Neither the attitude in response... > It's like you're happy to throw his work away at first occasion > without even trying to negociate. > Bad vibrations. > > Before you engage in this (war)path, please, please, discuss. > And remind this saying "il ne faut pas confondre vitesse et prÃ©cipitation". > If no agreement is found then, ok, you'll get a license to carry on. > > After the license problem, there is the technical compatibility problem. > Discussions about cross fork compatibility, compatibility layers or > libraries (a la GREASE) will have to occur anyway, be it about Andreas > library or from any other author. So you'll have to take time to > discuss. Don't consider this as lost time. These discussions are > considered necessary when they regularly happens in Pharo mailing > list, aren't they ? It shouldn't be that hard to convince Andreas to > change things like and:and:and:. For squeakToUtf8, I don't know, maybe > provide some automated rewrite rules, and produce an automated Pharo > version ? > > Please, discuss, argue, explain why you consider certain constructions > as bad style. Propose alternatives (be constructive - remember > coopetition ?). > I consider being unable to explain one's own choice as a weakness. > Don't be weak. > Come-on guys, despite Levente's cutting remark, you're not inferior to > squeakers ;) (and you don't have to answer to that stupid conclusion). > > Nicolas > > 2010/8/30 Mariano Martinez Peck<marianopeck(a)gmail.com>: >> >> >> 2010/8/30 Miguel Enrique CobÃ¡ MartÃnez<miguel.coba(a)gmail.com> >>> >>> El lun, 30-08-2010 a las 18:25 +0300, Igor Stasenko escribiÃ³: >>>> My 2 cents about WebClient. >>>> >>>> - it should be an (un)loadable external package, and i am fully agree >>>> with Andreas on this point. >>>> It is tempting to integrate it into image, do some tweaks here and >>>> there and then ship it within a monolitic image. >>>> But then, from maintainer's point of view, it is quite hard to keep >>>> developing it and improving, since it may break >>>> things in random places over multiple forks etc etc, and then who will >>>> be accused in such breakage? - a maintainer. >>> >>> Of course not, we, the ones using it as part of our core image are the >>> ones responsible of the correct functioning in our image. It would be >>> childish to run crying to Andreas that it break our image because we are >>> taking the decision of integrating it in the core image. Now, this of >>> course doesn't apply to core functionality or that breaks the contract >>> the code offers to its clients. That type of API changes will be >>> discussed with Andreas and if no solution found, the pharo developers >>> will found a workaround so that is remains working correctly. >>> >> >> Agree with Miguel. It is the smae situation as Gofer. Lukas is the main >> developer of Gofer but we (pharo developers) maintain it. When a message is >> removed or renamed for example, we take care about its senders, for all >> packages, included Gofer. And we are the responsible, not Lukas. >> >>> >>> What I don't understand is why such imposition to the way of use the >>> software. If it decided to have an open source license he can't restrict >>> the uses of the software. This is a real open source implications. >>> >>> >>>> >>>> It is good to have a person, who personally responsible for >>>> maintaining a package, or even if by a group of people, >>>> it should use a separate repository for developing it. >>>> >>>> Otherwise, if you integrate it into image, by doing that you: >>>> - losing a maintainer , who willingly contributing to this project >>>> - in same turn, must take own responsibility for maintaining it, >>>> which means extra work for you, whenever you having >>>> problems with it. >>> >>> Of course, that is the point. Nobody expects otherwise. >>> >>>> >>>> We should learn how to integrate things without intimately tying >>>> everything with a single bloated image. >>> >>> Isn't as we are integrating moose or seaside in the core image is a >>> basic infrastructure thing, a http client, that every modern language in >>> the current times includes in their core libraries (java, ruby, lisp). >>> >>>> And WebClient could be right thing for learning that (Seaside too ;). >>>> >>> >>> >>> -- >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> 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

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

by Friedrich Dominicus

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

Aug. 31, 2010

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

by Friedrich Dominicus

"Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> writes: > Levente, > > I stand by the analogy of GPL's history and the more emotional > undertones of the current discussion. Dismissing it won't make it go > away. IMHO you are fully right. The fact still is if something is OS it forkable. Maye under certain conditions but it surely is forkable. I avoid GPL software as much as I can (but well I'm running Debian Linux) so there's not escape really. However I'm just using it... Makes life easier ;-) Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Aug. 31, 2010

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

by Schwab,Wilhelm K

Levente, I stand by the analogy of GPL's history and the more emotional undertones of the current discussion. Dismissing it won't make it go away. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Monday, August 30, 2010 6:47 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final On Mon, 30 Aug 2010, Schwab,Wilhelm K wrote: > GPL is designed to hold people (mostly commercial interests) hostage. Some of what is going on here sounds the same: it's open but not really. A web client is not so terribly difficult to write that we should compromise on licensing in order to use one. I have a *terribly* simple one that I can port if there is interest. IIRC, I used it to download some large files, but don't expect much. GPL was just an example for an open source license with restrictions, it has nothing to do with WebClient. Btw WebClient is far from simple (it's also a server, handles redirects, special responses, can support SSL, etc). Levente > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Monday, August 30, 2010 6:25 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final > > On Mon, 30 Aug 2010, Friedrich Dominicus wrote: > >> Levente Uzonyi <leves(a)elte.hu> writes: > >> On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: >> >>>>> >>>>> I suggest that the people that want and know, group together and build an open-source one. >>>> >>>> Why do you have to have your "own" library? >>> >>> Did I say "pharo library"? reread carefully I said an "open-source one". >> >> What I get from Andreas' words is that he's willing to make it open >> source if it won't be forked. > Hm I think this is impossible. If it's OS it's up to whomever get its > hand on it. Or am I mistaken? > > > Just think about GPL, it's open source, but you can't fork the code if you > don't release your changes as GPL too. > > > Levente > > > Regards > 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 > > _______________________________________________ > 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] SerialPort - named ports on Linux

by Schwab,Wilhelm K

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 > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ _______________________________________________ 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] SerialPort - named ports on Linux

by David T. Lewis

Sure, I think that should work fine. Dave On Mon, Aug 30, 2010 at 04:27:15PM -0400, Schwab,Wilhelm K wrote: > Dave, > > It's not obvious to me that Pharo won't take strings, but it looks that way because Squeak 4.1 has tests on type and by-name methods that are not in Pharo. One thought I had was to file the class out of Squeak and into Pharo, perhaps fixing _ vs. := and any other hassles that might arise. > > Should that work? > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] > Sent: Monday, August 30, 2010 4:25 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] SerialPort - named ports on Linux > > On Mon, Aug 30, 2010 at 02:24:37PM -0400, Schwab,Wilhelm K 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, > > I don't have a Pharo image handy to check right now, but look at class SerialPort. > Methods such as #openPort: should accept either integer (port number) or string > (named device) parameters (if not, grab it from a Squeak image). All changes are > in the VMs already, so there is nothing to worry about on the VMMaker side. > > If you need the background on this, it's at http://bugs.squeak.org/view.php?id=7266. > > Dave >

Aug. 31, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by Serge Stinckwich

On Mon, Aug 30, 2010 at 4:57 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 30, 2010, at 4:28 AM, Sudhakar Krishnamachari wrote: > >> >> Good to see some of the concerns addressed. >> >> " >> Now so far I do not see companies really putting effort so may be nothing will happen but this will not be >> Â Â Â because of us. :)" >> >> >> This is the chicken and egg situation. Bar highly motivated startups with some money in their pockets to splurge on with. The average co consists of average managers who want no risk..!. They want a technology they can blame for its shortcomings/ the support offered by another co if they are stuck for a fix. But in most ( I would say 90+% of timeline) cases the business continuity should not be affected. > > Sure this is clear. > Now my point is pragmatic. > >> The average company will probably not invest their time on a technology if it does not meet the bar set by the current technology. > > Well lot of companies are using seaside and pharo and as such the fact that the infrastructure is getting better is important. > >> >> Let me take Spring Architecture as an example in the Java world. J2EE was ( and to an extent is) entrenched in the world of Java enterprise. Way back about 8 yrs back or so .. Rod Johnson started his foray in to simplifying the complexity of J2EE with his framework. I would say through atleast 4+ yrs of the 8 he would have close to nil support from any company and like the Jim Collins "Good to Great" simile built up the giant wheel momentum now to engage nearly all known companies to use Spring all through instead of J2EE except in the niche cases. Its is an instruction to notice how Spring got interfaces to nearly all of Java connected that would be possibly needed for a medium enterprise case and then went into the depths/ specialization etc.. that is breadth first and then the depth. >> >> So I would say "WE" (including myself as a avowed Smaltalker) need to keep trying and pushing for a concerted go at getting Pharo up there.. and possibly the "GiantWheel momentum" will kick in with first a few co's and then more.. to push this rolling with god speed to its eventual greatness..!!.. > > welcome! > >> And that indeed is happening and its suprised me how far Pharo has already rolled and is building a momentum that is sure to go far if I can put my little effort as all others to get some of the minimal frameworks integrated. > > we need help > >> We have either of two approaches to take: meet up to the current bar set by Java/ .Net world in terms of programming baseline ( as I listed in the prior mail) or take a radical approach that differs so much and offers so much to pull in others..like Rails did. I would say if we are interested in the numbers game I would choose the former, if we wish to retain the intellectual high ground and move on the latter is fine.. > > we can have a vision, a vision without action does not exist. > What we are doing are > Â Â Â Â - providing robust infrastructure > Â Â Â Â - making the system lean and clean > Â Â Â Â - slowly rewriting parts > now if people with other agendas want to focus on other parts we are more than happy. > > >> >> To get the numbers to have an interest in Â Pharo I will go back to my charter for Smalltalk spread in Universities / Colleges ( the underlying reason I started SmalltalkIndia) and see how far it can be resuscitated to create a mass base of users ( even if they are amateurs) and then hope a good percentage of them retain a greater interest to contribute spare time to improve the frameworks in Pharo. > > Would be great. Let me know how I can help > Do you know I have free slides? > Â Â Â Â http://stephane.ducasse.free.fr/Resources/LecturesInPowerpoint/ Great Skrish ! Can you say a bit more on your indian Smalltalk User Group ? Do you have any website ? I'm located in Vietnam (Ha Noi) and want to foster Smalltalk in Asia (especially in South-East Asia). I just spend 2 weeks in Japan and meet some Japanese Smalltalkers in Tokyo. I'm also interested to visit India to meet Smalltalkers in 2011. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Aug. 31, 2010

Re: [Pharo-project] OBMorphicIcons (was Re: this style looks cool)

by Rob Rothwell

Thanks both of you for pointing me in the right direction. I was able to get something similar to what is in OBMorphicIcons>>breakpoint by doing this: methodContents := WriteStream on: ''. (OBMorphicIcons iconNamed: #breakpoint) storeOn: methodContents. methodContents inspect. But the contents are different, and if you substitute them for the contents of breakpoint, the picture looks different too... Thank you, Rob > *contents := (StandardFileStream fileNamed: 'loop_icon.jpg') contents. > encondedContents := (Base64MimeConverter mimeEncode: contents readStream) > .* > > That basically gives you the string you have to embed in a method... > > Cheers, > Guille > > On Mon, Aug 30, 2010 at 9:42 AM, Alexandre Bergel <alexandre(a)bergel.eu > >wrote: > > > > > > > This looks useful; how do you turn an image into a method, though? > > > > Hi! > > > > Have a look at the class side of MenuIcons. There are a bunch of > > import/export methods. > > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >

Aug. 31, 2010