- Pharo-dev - lists.pharo.org

[Pharo-project] Next step in cleaning DataStream

by Mariano Martinez Peck

So, so far we have removed SmartRefStream, deprecated ReferenceStream and integrated Fuel. The ONLY remaining user for DataStream is Monticello. We do not want to replace that yet because Fuel may still change the format and we do not want to break monticello versions. But, my question is now...should we clean DataStream and assume its only usage will be the definitions of Monticello? becuase I true, I think we may be able to remove DiskProxy and all its users, togethet with lots of methods like #objectForDataStream: what do you think? -- Mariano http://marianopeck.wordpress.com

June 4, 2012

Re: [Pharo-project] What i would like to have instead of progress bar

by Chris Muller

I know I'm late to the discussion, but I thought I'd share features of my own design of MaClientProcess, which has been part of the Maui framework for Squeak since 2004, how it handles progress. It is based on the ultimate progress-bar handling I did in VisualAge and published in 1997: - The ClientProcess runs in the background, of course. - It's UI can be placed anywhere on the desktop, or minimized. - Shows time elapsed and estimated time remaining. - Shows units processed as a fraction of total units. - Allows descriptions of sub-tasks being worked on to be displayed. - Doesn't appear at all unless the task takes more than 5 seconds to complete, that way the system is not presenting progress bar and then immediately removing it. - Allows the user to PAUSE or change the priority of the Process -- generically without client code knowing anything about that. - No nesting. - UI updates based on a time-interval rather than client processing so that performance is NOT affected. On Thu, May 31, 2012 at 6:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) > how the indication of a progress of some process should look like, > here's my potential answer: > > > - a tiny one line in a corner of desktop (instead of huge banner > centered in window, > Â sticking on top of everything and obscuring the view) > - not blocking user input > - no stupid nesting.. i don't care what happens inside of something > else happens.. > if it is really necessary, i would just replace the title of a task > with it's subtask title while it performing. > this is just about first rule: it has to be a single line, not a bunch > of lines stocking one over another.. > i think this is abuse. > > most of the times, i just need a notion of progress of a whole thing, > not progress of it's subthings > (if user really wants, he can hover the mouse over progress line to > see the details, but by default > it should take minimal space on the screen). > > > > -- > Best regards, > Igor Stasenko. >

June 4, 2012

Re: [Pharo-project] Trouble loading XML RPC

by Noury Bouraqadi

Hi GermÃ¡n, Thanks for your answer. Indeed, I tried with Pharo 1.4. And had the same issues. My plan is to port XML RPC to Pharo 2. I'm interested on your work with Zinc. Where is it available ? Can I get write access grant to the repo, so I can upload any improvement I do ? What I wanted to do is to cut off everything not XML RPC and complete based on sUnit tests. BTW, any simple way to load all SUnit tests for all packages ? I started analyzing the ConfigurationOfxxx classes. ConfigurationOfXMLSupport includes some references that I would like to have some hints on them (where they are used): - Grease - Opax - Pastell - SiXX - XML-Observable Thanx, Noury On 3 juin 2012, at 17:26, garduino wrote: > Hi: > > Sorry the late answer.... > > If you take an 1.4 stock image, and evaluates (as is commented on > http://code.google.com/p/pharo-xmlrpc/) > > Gofer it > url: 'http://ss3.gemstone.com/ss/XMLRPC'; > package: 'ConfigurationOfXMLRPC'; > load. > > and then: > > > (ConfigurationOfXMLRPC project version: '1.0-Beta4') load: 'All'. > > the whole stuff should load. > > I noticed an error: > > This package depends on the following classes: > TranscriptStream > You must resolve these dependencies before you will be able to load these > definitions: > isTranscriptStream > > (May be another thing changed in Pharo that I need to know and fix, press > proceed to load anyway). > > But the bad new is that in 1.4 I've some errors on tests, mainly a serious > one in server that freeze the image, caution. However, the XMLRPC Client > seems to work. > > XMLRPC is always in my to-do list but a project in what I can invest only a > portion of my limited free time. > > The latest new was that I adapted the Client to use with Zinc, but need > still to make the same thing with the server, then all xmlrpc should install > and run in a stock image, without need Komanche for example. > > With respect to Pharo 2.0 I can't help, not tried yet. > > HTH. > GermÃ¡n. > > > > > > -- > View this message in context: http://forum.world.st/Trouble-loading-XML-RPC-tp4632653p4633037.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

June 4, 2012

Re: [Pharo-project] [ConcreteTypeInference] news.

by Santiago Bragagnolo

Thanks :3, i working a lot. ea, ahora me suscribo!. 2012/6/4 Edgar J. De Cleene <edgardec2005(a)gmail.com> > > > > On 6/3/12 10:31 PM, "Santiago Bragagnolo" <santiagobragagnolo(a)gmail.com> > wrote: > > Hi all! > > > I'm announcing four new posts on the blog, > > Concrete types - A little brief about concrete types to understand the > mechanisms > *http://concretetypeinference.blogspot.com.ar/2012/06/concrete-types.html > * > About mechanisms part 1 - talking about problems getting green the tests > :). This revision is about contexts of block evaluation > * > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > * > About mechanisms part 2 - This revision is about a pretty weird scenario > * > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > * > Metacello configuration - nothing to add to the title. > * > http://concretetypeinference.blogspot.com.ar/2012/06/metacello-concretetype… > * > > Good week. > > I enjoying your blog and your work. > Please continue. > > Y me gustarÃa te unas a http://ar.groups.yahoo.com/group/squeakRos/ > > Edgar >

June 4, 2012

Re: [Pharo-project] Log fwk

by Santiago Bragagnolo

Yeah. i was waiting for the integration of TAnnouncer to announcements, but well, i added just now a copy with other name. In other words, theres no more Tannouncer bug :) Thanks for the feedback! 2012/6/4 Edgar J. De Cleene <edgardec2005(a)gmail.com> > > > > On 6/3/12 8:11 PM, "Santiago Bragagnolo" <santiagobragagnolo(a)gmail.com> > wrote: > > I have added a metacello configuration for the project: > There's only one version, so bleeding edge. > > Gofer new > squeaksource3: 'PaulLePoulpe'; > package: 'ConfigurationOfPaulLePoulpe'; > load. > > ConfigurationOfPaulLePoulpe project bleedingEdge load > > > > In both Pharo 1.4 and Pharo 2.0 updated I get this odd: > > Gofer new > Argument expected ->squeaksource3: 'PaulLePoulpe'; > package: 'ConfigurationOfPaulLePoulpe'; > load. > > When I do by hand, start to load until I got the attached error. > > Edgar >

June 4, 2012

Re: [Pharo-project] Log fwk

by Edgar J. De Cleene

On 6/3/12 8:11 PM, "Santiago Bragagnolo" <santiagobragagnolo(a)gmail.com> wrote: > I have added a metacello configuration for the project: > There's only one version, so bleeding edge. > > Gofer new > Â Â Â squeaksource3: 'PaulLePoulpe'; > Â Â Â package: 'ConfigurationOfPaulLePoulpe'; > Â Â Â load. > Â Â Â > ConfigurationOfPaulLePoulpe project bleedingEdge load In both Pharo 1.4 and Pharo 2.0 updated I get this odd: Gofer new Â Â Â Argument expected ->squeaksource3: 'PaulLePoulpe'; Â Â Â package: 'ConfigurationOfPaulLePoulpe'; Â Â Â load. When I do by hand, start to load until I got the attached error. Edgar

June 4, 2012

Re: [Pharo-project] [ConcreteTypeInference] news.

by Edgar J. De Cleene

On 6/3/12 10:31 PM, "Santiago Bragagnolo" <santiagobragagnolo(a)gmail.com> wrote: > Hi all! > > > Â I'm announcing four new posts on the blog, > > Concrete types - A little brief about concrete types to understand the > mechanisms > http://concretetypeinference.blogspot.com.ar/2012/06/concrete-types.html > > About mechanisms part 1 - talking about problems getting green the tests :). > This revision is about contexts of block evaluation > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > locks-on.html > > About mechanisms part 2 - This revision is about a pretty weird scenario > http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… > locks-called.html > > Metacello configuration - nothing to add to the title. > http://concretetypeinference.blogspot.com.ar/2012/06/metacello-concretetype… > erence-project.html > > > Good week. > > I enjoying your blog and your work. > Please continue. > > Y me gustarÃa te unas a http://ar.groups.yahoo.com/group/squeakRos/ > > Edgar

June 4, 2012

[Pharo-project] Slides and Pictures PharoConf

by Marcus Denker

Hello, We now have an archiving page for PharoConf2012: http://rmod.lille.inria.fr/web/pier/Events/PharoConf2012 This has all Slides, Success Story presentations and the slides from the "Speed Dating" session. In addition, there are some photos for the two day. Marcus -- Marcus Denker -- http://marcusdenker.de

June 4, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Phil (list)

Igor, On Jun 4, 2012, at 1:55 AM, Igor Stasenko wrote: > On 3 June 2012 18:01, Phil (list) <pbpublist(a)gmail.com> wrote: >> On Jun 3, 2012, at 11:31 AM, Marcus Denker wrote: >> >>> >>> How do people do it with Java? Java .jar files are as easy to decompile as Smalltalk bytecode... >>> >> >> ProGuard (http://proguard.sourceforge.net/) is a popular method. In its obfuscation phase it will rename most class and method names (i.e. anything that doesn't need to be externally visible) to meaningless names so MyClass.MyMethod becomes something like a.a. It can also generate a mapping file so that when bug reports / crashes occur, the developer can map the gibberish names back to the original names. Before the obfuscation phase, it has optimization and shrinking phases to eliminate code that doesn't need to be included for release (debugging code etc.) >> > > so, what prevents others from writing de-obfuscating tool and then > read nice sources? De-obfuscating what? The reverse mapping resides with the developer. So a determined hacker can see that class 'a' has methods 'a', 'b', 'c' and has instance vars 'a', 'b', 'c', 'd', and 'e'. (Literally, that's what the names get turned into) Granted, there are some clues left behind (a few classes/methods that need to be externally referenced and classes/methods that your code calls out to), but *your* code has essentially been turned into high-level undocumented assembly code that won't be that much more obvious than what can be produced by a good disassembler. One weakness of ProGuard obfuscation is that it is fairly static in its mapping (though even if they randomized it a bit, it probably wouldn't be that hard to do a structure-diff of the code to figure out how the latest release mapped to an older release using a tool like Moose)... i.e. you get a bit of naming drift as the number of classes and methods change, but the order of mapping is static. > > no matter what you do, as long as you distribute executable code to > masses, it can be reverse-engineered. You can only make it harder. > But there is good way to prevent this from happening: stop selling > binary files, > start selling real support for your software, ship updates regularly, > make customers happy. > Then you will be immune from any piracy, because nobody will think > pirating your software, > because it is useless without your support. > I agree that it does nothing to prevent reverse-engineering by someone who's dedicated and getting support provides significant value. The situation is no different with with languages that emit true binary code: if it can be run on the users machine, it can be cracked/reverse-engineered. However, it does make the effort quite a bit more tedious without intention revealing names. I've decompiled several of my own obfuscated Java apps and come to the conclusion that if I were attempting to reverse-engineer my own stuff without the knowledge of why things ended up as they did, I'd have a much easier time just reimplementing it as knowing what I did doesn't help me at all with the 'why'. Sure, if one had a highly valued application a group of like-minded individuals could figure it out in short order... but ah, what a problem to have :-) Anyway, I was just trying to address the question of how Java apps address the issue. > > > -- > Best regards, > Igor Stasenko. > Thanks, Phil

June 4, 2012

Re: [Pharo-project] ClassBoxes... bitrotted, or usable?

by StÃ©phane Ducasse

Hi jan > - having a class Selector that get evaluated into a symbol. You can then achieved selector namespaces, which does not incur a cost at execution. Indeed we should just agree that this is the semantics we want for class extensions for example :) Jan did you have a look at http://timelessrepo.com/refinements-in-ruby Because I would like to know if there are more selector or classbox oriented or something else? Stef . > I do not understand the idea. Could you give an example? > > > Cheers, Jan > > > >> >> Cheers, >> Alexandre >> >> >> On Jun 1, 2012, at 10:55 AM, Frank Shearar wrote: >> >>> I mused with a colleague about how I'd like to see "lexically scoped >>> monkey patching", and he pointed me to some guys that want to add that >>> to Ruby (http://timelessrepo.com/refinements-in-ruby) Note the >>> inspiration for their work: ClassBoxes! >>> (http://scg.unibe.ch/research/classboxes) >>> >>> I remember reading the paper years ago, and started working through it >>> again now. Something that's not clear to me is this: does ClassBoxes >>> require VM-side changes? (Because it changes the method lookup, after >>> all, searching packages for methods before working up the inheritance >>> tree.) If so, how invasive are they? If not, do we have a ball-park >>> estimate of how much work it would be to update ClassBoxes to a more >>> recent Squeak/Pharo? >>> >>> I'm more than happy to do the dogwork. I'd just like to know whether >>> I'm signing up for months of work or not. >>> >>> Thanks! >>> >>> frank >>> >> > >

June 4, 2012