- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Pharo 1.4 Released

by Benjamin

On Apr 23, 2012, at 4:31 PM, Camillo Bruni wrote: > > On 2012-04-21, at 20:08, Sean P. DeNigris wrote: > >> What a tremendous list of accomplishments!! I'm blown away every time I read >> it... >> >> Are there more detailed descriptions of these bullets? Specifically I'm >> interested in: >> >> Marcus Denker-4 wrote >>> >>> - Better primitive simulation > > the following two go together, see http://code.google.com/p/pharo/issues/detail?id=4617 > mainly the startup handling has been made more robust and decent command-line notifications have been added. > so you will get a nicely colored stack-trace when loading a script with an error. Plus CodeLoader has been simplified >>> - Better headless support >>> - Better support for error at startup > > I guess the new ClassSearch popping up in Nautilus / Browser on cmd/ctrl-F > + MC / TestRunner search fields on top of the lists a bit buggy but useful ;) Ben >>> - Search in tools >>> - Better search > >

April 23, 2012

Re: [Pharo-project] The video about Athens

by Marcus Denker

On Thu, Apr 19, 2012 at 4:42 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, all > > I recorded a small introductory video about Athens. > Here it is: > > http://vimeo.com/40653315 > > (about 21 minutes). > The Audio track is now working. -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

April 23, 2012

Re: [Pharo-project] Pharo 1.4 Released

by Camillo Bruni

On 2012-04-21, at 20:08, Sean P. DeNigris wrote: > What a tremendous list of accomplishments!! I'm blown away every time I read > it... > > Are there more detailed descriptions of these bullets? Specifically I'm > interested in: > > Marcus Denker-4 wrote >> >> - Better primitive simulation the following two go together, see http://code.google.com/p/pharo/issues/detail?id=4617 mainly the startup handling has been made more robust and decent command-line notifications have been added. so you will get a nicely colored stack-trace when loading a script with an error. Plus CodeLoader has been simplified >> - Better headless support >> - Better support for error at startup I guess the new ClassSearch popping up in Nautilus / Browser on cmd/ctrl-F + MC / TestRunner search fields on top of the lists >> - Search in tools >> - Better search

April 23, 2012

[Pharo-project] The Squeak vs Pharo hostility... (was Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk)

by GÃ¶ran Krampe

Hey all! On 04/23/2012 03:43 PM, StÃ©phane Ducasse wrote: >>> It doesn't really matter who started it. We all like to come over this. It can happen and the only thing making it worse is to talk about the fact that it happened. >> >> Yeah, I don't care either about who started it - I am just tired of it :). > > May be other people are tired by other aspects? > No? I guess so. I don't follow. What do you mean? > We have a vision and people can help making it true or not. :) > But our goal is to support business emerge (with our little mean) but we try hard. I know and I am all behind it, 100%. The thing is, this "history" behind the Squeak/Pharo divide is still lurking between the lines and I (personally) am tired of it. For example, I often get the feeling that my posts to this list raise replies as if I am some kind of "outsider", just because I was heavily involved in Squeak earlier or something. I am a Pharoer too. I may be more of a bystander these days than a contributor (since I don't have a lot of time to spend) - but I am only using *Pharo* these days, not Squeak. Yup, sorry Squeak, but it is just the reality. I *still* wish the best for Squeak though, and all other open source or commercial efforts in the Smalltalk arena. I think it would be nice if we all could be a little bit more positive and inclusive, especially the people who are prominent in our (overlapping) communities - you set the example. :) I really don't see any gain in Pharo spewing negatives over Squeak, Squeak is still the inheritage of Pharo and I for one am proud of the friendliness of the Smalltalk community. Nor of course see I any gain in spewing in the other direction, it goes both ways. Now, I suspect this light criticism wrapped up in smileys and all, and with all the good intentions, will still lead to negative replies. But I hope not. Perhaps time to simply move on? ;) regards, GÃ¶ran PS. I love all the momentum in Pharo right now, it all looks very good, and I am itching digging into 1.4! Superb work.

April 23, 2012