- Pharo-dev - lists.pharo.org

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

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

by Serge Stinckwich

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/

Aug. 31, 2010

Re: [Pharo-project] return character magic?

by Eliot Miranda

2010/8/30 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > On 31.08.2010 01:32, Eliot Miranda wrote: > > Hi Henrik, > > twice you write a slip that the compiler should not allow: > > (map := characterToGlyphMap) > ifNotNil: [:map | code := map at: code + 1]. > > code := (map := characterToGlyphMap) > ifNil: [aCharacter charCode] > ifNotNil: [:map | map at: aCharacter charCode + 1] > > these should read > > characterToGlyphMap ifNotNil: [:map | code := map at: code + 1]. > > code := characterToGlyphMap > ifNil: [aCharacter charCode] > ifNotNil: [:map | map at: aCharacter charCode + 1] > > HTH, > Eliot > > Hum, unless I posted a previous version, the code in the changeset was: > > characterToGlyphMap ifNotNil: [:map | code := map at: code +1]. > and > code := characterToGlyphMap > ifNotNil: [:map | map at: aCharacter charCode +1] > ifNil: [aCharacter charCode]. > > Seem to me they got decompiled somehow? > Oops, quite right! I think I did pretty diffs and this is what I got. Bad pretty diffs, bad :) > > > > also in BitBlt>>#primDisplayString:from:to:map:xTable:kern: you write > > ascii := glyphMap at: (aString at: charIndex) asciiValue + 1. > > whereas the current Squeak code reads > > ascii := (aString at: charIndex) asciiValue. > glyphMap ifNotNil:[ascii := glyphMap at: ascii+1]. > > Should Squeak keep its original code (which seems equivalent) or is there > a specific reason to eliminate the ifNotNil: test? > > TIA > Eliot > > Yes, it should keep it. > Getting late, I made that change in that method first to have Pharo display > correctly, and didn't yet think of that glyphMap may be nil :) > For Squeak, the two methods in StrikeFont should be sufficient. > Cool, thanks! Eliot > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

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

by Henrik Sperre Johansen

On 31.08.2010 01:21, Levente Uzonyi wrote: > On Tue, 31 Aug 2010, Henrik Sperre Johansen wrote: > > snip > >> Yeah, that's why I added the 200000 4KB docs / sec number. >> I really doubt the conversion will be a significant part of the >> processing time if what you send out is so small you are able to >> convert 800k messages per second... > > It depends on the machine/load/etc. I feel like we already had this discussion over the cull: implementation, and I doubt either of us is going to change their mind, so let's stop here :) > >> >> See the code I attached last mail, switching to convertToEncoding: >> 'utf8' sort of implied implementing something like that, which gives >> it nearly the same speed as convertToWithConverter: UTF8TextConverter >> new in your examples. > > Sorry, I didn't see that. It looks cool, but I still wouldn't use > #convertToEncoding: in my code, because there's a similar looking > method (#converToWithConverter:) with better performance :). Sure, though I find it quite ugly, I wouldn't vehemently oppose using it either, but the issue here was finding something Andreas would accept :) > But it's definitely better than the current version, though if a > converter is added/changed/removed, the dictionary has to be updated > manually. > > > Levente Yeah, the code was merely a proof of concept to show off that you could get acceptable (for some :P) performance using it, as a middleground between squeakToUtf8 and convertToWithConverter in terseness. Cheers, Henry

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by Henrik Sperre Johansen

On 31.08.2010 01:32, Eliot Miranda wrote: > Hi Henrik, > > twice you write a slip that the compiler should not allow: > > (map := characterToGlyphMap) > ifNotNil: [:map | code := map at: code + 1]. > > code := (map := characterToGlyphMap) > ifNil: [aCharacter charCode] > ifNotNil: [:map | map at: aCharacter charCode + 1] > > these should read > > characterToGlyphMap ifNotNil: [:map | code := map at: code + 1]. > > code := characterToGlyphMap > ifNil: [aCharacter charCode] > ifNotNil: [:map | map at: aCharacter charCode + 1] > > HTH, > Eliot Hum, unless I posted a previous version, the code in the changeset was: characterToGlyphMap ifNotNil: [:map | code := map at: code +1]. and code := characterToGlyphMap ifNotNil: [:map | map at: aCharacter charCode +1] ifNil: [aCharacter charCode]. Seem to me they got decompiled somehow? > > also in BitBlt>>#primDisplayString:from:to:map:xTable:kern: you write > > ascii := glyphMap at: (aString at: charIndex) asciiValue + 1. > > whereas the current Squeak code reads > > ascii := (aString at: charIndex) asciiValue. > glyphMap ifNotNil:[ascii := glyphMap at: ascii+1]. > > Should Squeak keep its original code (which seems equivalent) or is > there a specific reason to eliminate the ifNotNil: test? > > TIA > Eliot Yes, it should keep it. Getting late, I made that change in that method first to have Pharo display correctly, and didn't yet think of that glyphMap may be nil :) For Squeak, the two methods in StrikeFont should be sufficient. Cheers, Henry

Aug. 30, 2010