April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by GÃ¶ran Krampe

On 04/23/2012 05:02 PM, StÃ©phane Ducasse wrote: >>>> Just cloning it off into Pharo and forking seems... less optimal. Any ideas or thoughts? >>> >>> I do not get what you mean. I just want to work on our roadmap and make it getting real. >>> It is hard enough to get some momentum and to deliver for real. >>> So can you help us to get focused? >>> People can do what they want. I wrote a vision document. We have a roadmap >>> and we will do it. >> >> Ok, let me clarify. I was just wondering how the Pharo community wants to handle a case where a substantial component (in this case, this new editor) is not *primarily* developed in Pharo (in this case Cuis). >> >> The simple route is to just copy and fork. But IMHO this doesn't leverage the team already around this editor, right? We (Pharo) can't just go around and forking everything and maintaining everything for ourselves, right? > > But this is not that simple since Cuis layout is different and juan changed a lot the code. > We are also cleaning morphic so there is no magic. > >> I just got interested in that problem - now, later replies indicated that it would still need a substantial rewrite for Pharo, so perhaps the situation I am describing is not really applicable in this case. > > Kind of > I already talked at ESUG last year about that with bernahrd. Ok, good! cheers, GÃ¶ran

April 23, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Sven Van Caekenberghe

On 23 Apr 2012, at 16:04, GÃ¶ran Krampe wrote: > Ok, let me clarify. I was just wondering how the Pharo community wants to handle a case where a substantial component (in this case, this new editor) is not *primarily* developed in Pharo (in this case Cuis). GÃ¶ran, You know that many packages, even some very large ones, are reasonably portable. But I guess portability kind of stops when non-trivial GUI usage is involved. Also, as Pharo is making more and more changes, portability will become harder and harder until it is mostly gone. There are only two solutions: - write your own code to a least common feature set and miss all the new APIs - halt all non-compatible changes in Pharo and stop its evolution Neither are attractive options I guess. Sven

April 23, 2012

Re: [Pharo-project] new icon set

by Esteban Lorenzano

already checked, it is: http://creativecommons.org/licenses/by/2.5/ which I think is compatible enough :) Esteban On Apr 23, 2012, at 5:06 PM, Damien Cassou wrote: > On Mon, Apr 23, 2012 at 3:28 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I just hacked (well, yesterday, I was bored in my room) a new icon set for pharo, based on famfam icons. > > Please first check licenses are compatible > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

April 23, 2012

Re: [Pharo-project] new icon set

by Damien Cassou

On Mon, Apr 23, 2012 at 3:28 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > I just hacked (well, yesterday, I was bored in my room) a new icon set for > pharo, based on famfam icons. Please first check licenses are compatible -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

April 23, 2012

Re: [Pharo-project] monticello repos speedup

by Camillo Bruni

On 2012-04-23, at 16:56, Sven Van Caekenberghe wrote: > Camillo, > > On 23 Apr 2012, at 16:26, Camillo Bruni wrote: > >> I figured a specific bottleneck of the current implementation of MC is the uniqe version name check. >> >> On gemstone this takes 4 seconds! for the pharo inbox, definitely too longâ¦ > > That seems like a problem with the SS3 and/or GemStone server. I should be much faster: > > [ MCHttpRepository new > parseFileNamesFromStream: (ZnClient new > beOneShot; > get: 'http://mc.stfx.eu/ZincHTTPComponents') readStream ] timeToRun 227 > > (this is for half that many versions, admitted cached in RAM on the mc.stfx.eu server) well 500ms would be the standard range I expected (as for all gemstone requests) - your repos is much faster in that sense - so will smalltalkhub (from what I saw) I filed a bug report on gemstone, see if there can be done anything. >> The culprit can be found here >> >> MCFileBasedRepository >> includesVersionNamed: aString >> ^ self allVersionNames includes: aString >> >> assuming that the PharoInbox consists of quite some versions (currently 947) this is quite some overhead. > > It would be possible to skip the check all together, and fail when there is a conflict. > In a Distributed VCS you can never be sure anyway, right ? > For me commiting is always slow due to my large package cache. as previously discussed yes! the current uniqueness checks are quite flawed (closed world assumptions / race conditions) >> I would suggest the following improvements: >> >> - add a specific includesVersionNamed: server-side service >> - add a simpler allVersionNames service that returns a newline separated list of filenames (not an html doc!) > > Could be a solution I guess. > But checking whether a version exists could be as simple as a HEAD request, no ? actually true, will try > Then we would need almost no extra API, just a minor semantic change (with a fallback to a normal real GET). true > I don't know if the other format would really make much difference, but I have to admit it would be more logical. all in all the parsing part doesn't use that much time, but still too much work done for what it is :). >> By having specific MC repository implementations everything would be 100% backwards compatible since no services are removed nor is the default http repository implementation changed. > > Probably doable. > >> what do you think? > > BTW, do all repositories (actual, cache, others) have to be checked all the time ? > Can't we at least turn that into an option ? if you simply do a HEAD / single request it doesn't really matter anymore since it's going to be as fast as one single request. I currently do all checks in parallel so it's only a matter of the slowest one :)

April 23, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by StÃ©phane Ducasse

>>> Just cloning it off into Pharo and forking seems... less optimal. Any ideas or thoughts? >> >> I do not get what you mean. I just want to work on our roadmap and make it getting real. >> It is hard enough to get some momentum and to deliver for real. >> So can you help us to get focused? >> People can do what they want. I wrote a vision document. We have a roadmap >> and we will do it. > > Ok, let me clarify. I was just wondering how the Pharo community wants to handle a case where a substantial component (in this case, this new editor) is not *primarily* developed in Pharo (in this case Cuis). > > The simple route is to just copy and fork. But IMHO this doesn't leverage the team already around this editor, right? We (Pharo) can't just go around and forking everything and maintaining everything for ourselves, right? But this is not that simple since Cuis layout is different and juan changed a lot the code. We are also cleaning morphic so there is no magic. > I just got interested in that problem - now, later replies indicated that it would still need a substantial rewrite for Pharo, so perhaps the situation I am describing is not really applicable in this case. Kind of I already talked at ESUG last year about that with bernahrd. > > regards, GÃ¶ran >

April 23, 2012

Re: [Pharo-project] monticello repos speedup

by Sven Van Caekenberghe

Camillo, On 23 Apr 2012, at 16:26, Camillo Bruni wrote: > I figured a specific bottleneck of the current implementation of MC is the uniqe version name check. > > On gemstone this takes 4 seconds! for the pharo inbox, definitely too longâ¦ That seems like a problem with the SS3 and/or GemStone server. I should be much faster: [ MCHttpRepository new parseFileNamesFromStream: (ZnClient new beOneShot; get: 'http://mc.stfx.eu/ZincHTTPComponents') readStream ] timeToRun 227 (this is for half that many versions, admitted cached in RAM on the mc.stfx.eu server) > The culprit can be found here > > MCFileBasedRepository >> includesVersionNamed: aString > ^ self allVersionNames includes: aString > > assuming that the PharoInbox consists of quite some versions (currently 947) this is quite some overhead. It would be possible to skip the check all together, and fail when there is a conflict. In a Distributed VCS you can never be sure anyway, right ? For me commiting is always slow due to my large package cache. > I would suggest the following improvements: > > - add a specific includesVersionNamed: server-side service > - add a simpler allVersionNames service that returns a newline separated list of filenames (not an html doc!) Could be a solution I guess. But checking whether a version exists could be as simple as a HEAD request, no ? Then we would need almost no extra API, just a minor semantic change (with a fallback to a normal real GET). I don't know if the other format would really make much difference, but I have to admit it would be more logical. > By having specific MC repository implementations everything would be 100% backwards compatible since no services are removed nor is the default http repository implementation changed. Probably doable. > what do you think? BTW, do all repositories (actual, cache, others) have to be checked all the time ? Can't we at least turn that into an option ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 23, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Chris Muller

>> Did your "Smalltalk Code Critic" tell you that or just another one of >> your biased opinions? > > Wow, why so aggressive? Not aggressive, just curious about what your point is Marcus? What is your point when you say something like, "isn't it amazing how bad Squeak is?" What does it mean when someone characterizes as "anarchy that runs in circles?" Or, another one I read recently on a blog comment: "Squeak is known to burn your eyes out. You should try Pharo!" It's all non-specific, non-helpful, antagonistic, fuddy-duddy nonsense. I've been rooting for Pharo (still am) and supporting it by blemishing my code on account of your whimsical renames, etc., so it will continue to run there. If you would lead a reciprocation of this sort of good will rather than divisive idle-commentary, it could be more productive. > Do you really do *not* see the problems that there are in Squeak? Of course I do, that's why I'm part of a group that's addressing them. I also happen to see problems with Pharo and some of the wrong decisions that have been made, but that doesn't mean I'm going to go out of my way to disparage your hard work. >> -- even old versions from years past embarass programs >> like, say, PowerPoint. Â It's text-handling is fantastic -- remember >> the release image delivered with text on the desktop flowing out one >> text box, following along a loop-de-loop spline and into another text >> box? Â What other programs that can do that today in 2012..? >> > It's a toy example. Adding a character means re-flowing everything. > Unusable for larger texts. "Larger texts", a la gigantic Word documents from the 90's thru today? We should be moving toward smaller bits of linked-information anyway, like what I've done with MaOffice for Squeak. Anyway, it doesn't matter -- you're right, it was just an example illustrating the capability. - Chris

April 23, 2012

Re: [Pharo-project] Zodiak SSL on 1.4 problem

by Camillo Bruni

On 2012-04-23, at 16:42, Sven Van Caekenberghe wrote: > > On 23 Apr 2012, at 16:16, Janko MivÅ¡ek wrote: > >> Now I loaded Zodiac-Extra and Zinc-Zodiac and ZnHTTPSTests all pass. >> While below mentioned test still fails. > > OK, I will test again on Linux tonight myself to see for myself. > > The extra package that you loaded shouldn't make a difference on the functionality of Zdc itself, they just add stuff, like ZnHTTPSTests. > > Thx for reporting, > > Sven did you manually install the SSL extensions to the VM? Cause I think the VM currently build on our servers still include a buggy version of the SSL plugin :/ best cami

April 23, 2012

Re: [Pharo-project] Zodiak SSL on 1.4 problem

by Sven Van Caekenberghe

On 23 Apr 2012, at 16:16, Janko MivÅ¡ek wrote: > Now I loaded Zodiac-Extra and Zinc-Zodiac and ZnHTTPSTests all pass. > While below mentioned test still fails. OK, I will test again on Linux tonight myself to see for myself. The extra package that you loaded shouldn't make a difference on the functionality of Zdc itself, they just add stuff, like ZnHTTPSTests. Thx for reporting, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 23, 2012