- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Splitting network package
by Bill Schwab Jan. 9, 2009

Jan. 9, 2009

Michael, Excellent! I retract my re-iteration of the point :) Wasn't meaning to nag. You will find Ron capable (to say the least), helpful, etc. Thanks! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> m.rueger(a)acm.org 01/08/09 2:01 PM >>> Bill Schwab wrote: > Michael, > > It might be nice to involve the cryptography maintainers; their work > could probably just add onto the structure you create. Great suggestion! Will do Michael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] Splitting network package
by Bill Schwab Jan. 9, 2009

Jan. 9, 2009

No flame wars here. I do not yet know enough about the URL/I classes, but will gladly consider any good code. I will reiterate that it would be nice to get the cryptography guys involved (thinking of SSL in particular) if possible. Re complete replacement, as precedent, please note Nile. It is not in yet, but that is a stated goal, so I think you will find that such things will be given serious consideration. Now for something completely different - and what first grabbed my attention. You mentioned cherry picking changes. I cannot really offer any help just yet, except to note a couple of things that have been useful in Dolphin. The first is Ian Bartholomew's ChunkBrowser - it is a fantastic tool and should be ported/recreated in Pharo if at all possible. Obviously we would respect Ian's licensing terms, provide proper credit, etc. Did I mention that it is a NICE thing to have? :) I wrote and use a tool called Migrate for getting code out of one Dolphin image and into another. It has been sensitive to changes in the packaging system, but the general idea is to build a list of the currently installed packages and produce a script to load them into a new image. I added a concept of "safe" and "dangerous" loose methods. One might argue that only the dangerous methods (essentially overrides) are needed - I'm too tired to figure out why I have two types<g>, but I probably wrote it down somewhere. Migrate also arranges to file out and in those methods, but optionally on the in-side. I realize none of this is useful now, but I would expect to create Pharo versions of pieces that make sense in Pharo. Making sense will also be constrained in part by my level of use of Pharo over time. I have a LOT of Dolphin packages, so listing them in a sensible order is not a trivial task. I also hacked a few things that need to be reviewed when changing to a new version, and found ways to keep track of that w/o creating collisions with the base system packages. Feel free to run with any ideas that seem helpful. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> m.rueger(a)acm.org 01/08/09 1:51 PM >>> Hi all, updated MIME, URI and File packages in inbox. Some of the URI related changes are somewhat incomplete as I merged them from a different context. Hopefully I didn't break anything though :-) With merges like this it is really a problem that MC doesn't allow cherry picking changes... The overall goal with the URI changes is to complete replace the current Url implementation. We have done this quite successfully in Sophie and even more radically in the experimental ySqueak branch. Suggesting to replace Url classes by URI was a sure way to get a flame war going on the Squeak dev list. So what is general opinion on this for Pharo? Michael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Splitting network package
by Michael Rueger Jan. 8, 2009

Jan. 8, 2009

Hi all, while working on some unicode related stuff I ended up integrating some MIME changes from Sophie. For that I would like to split up the Network package into nine sub packages (Network-Kernel, Network-MIME, ...). Will also make it easier to update URI and MIME packages later etc. Hope that is ok with everybody. Michael

3 7

Re: [Pharo-project] Splitting network package
by Bill Schwab Jan. 8, 2009

Jan. 8, 2009

Michael, It might be nice to involve the cryptography maintainers; their work could probably just add onto the structure you create. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 1/8/2009 10:00:53 AM >>> Yes go! I would like to have packages and not category besides that I prefer lot of packages well designed than a fat one. Let us know when we can include your changes. Stef > Hi all, > > while working on some unicode related stuff I ended up integrating > some > MIME changes from Sophie. > For that I would like to split up the Network package into nine sub > packages (Network-Kernel, Network-MIME, ...). Will also make it easier > to update URI and MIME packages later etc. > > > Hope that is ok with everybody. > > Michael > > _______________________________________________ > 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

2 1

Re: [Pharo-project] [OT] Great job guys
by Dale Henrichs Jan. 8, 2009

Jan. 8, 2009

----- "Igor Stasenko" <siguctua(a)gmail.com> wrote: | 2009/1/7 Torsten Bergmann <astares(a)gmx.de>: | > see http://mue.tideland.biz/2009/01/great-job-guys.html | > -- | Since this is alredy OT ... | | by coincidence, i'm currently also working on GLASS, but still using | old squeak image. :) | Any success installing gemtools into pharo to use improved OB-based | look&feel? | Igor and Hilaire, I have been using Pharo with the GemTools/GLASS for several weeks now. You need to update to a new version of the GLASS package (using the old GemTools Client) and then you can create a new Pharo-based GemTools client using a recent Pharo dev image. Full instructions are located at [1] and [2]. Dale [1] http://gemstonesoup.wordpress.com/2008/12/24/glass-beta-update-tools-tuneup… [2] http://gemstonesoup.wordpress.com/2009/01/04/glass-beta-update-holiday-tool…

1 0

[Pharo-project] Buggy HTTPSocket in dev-image
by Andreas Wacknitz Jan. 8, 2009

Jan. 8, 2009

Hi folks, the dev images seem to have a (probably older version) of HTTPSocket. There are some undefined globals (like HTTPProxyServer, HTTPProxySocket, CrLf and CR) which lead to problems when I try to load Magma. The pharo-core image seem to have a correct version of this class. Cheers, Andreas

3 3

[Pharo-project] [ANN] 10203
by Adrian Lienhard Jan. 8, 2009

Jan. 8, 2009

- Issue 363: fix some traits issues (introduced by changes in Metaclass and TestCase) - Traits conflict marker methods stored in wrong cache - Remove duplicated method in trait and class that uses it (in collection tests) - Issue 315: darker colors in diff dialog (thanks to Damien Pollet) - Issue 342: Removing beginning capital letter of instance variables (Alexandre Bergel) - Make MC always display dependencies of a version in its summary text - Issue: 101: fasterDayOfYear-brp.1 (Mantis 7156) - Issue 102: better testPrintShowingDecimalPlaces Adrian ___________________ http://www.adrian-lienhard.ch/

3 8

Jan. 8, 2009

When I define a class with a trait and remove it after I get all the trait methods locally defined with a self halt. Does anybody know from where such a behavior could come from? Stef

2 4

Jan. 8, 2009

apparently this could be linked with the faster fasterDayOfYear-brp.1 (Mantis 7156)? Thanks for reporting stef Begin forwarded message: > From: "Rob Rothwell" <r.j.rothwell(a)gmail.com> > Date: January 8, 2009 3:01:07 AM CEST > To: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] [ANN] 10203 > Reply-To: rjriv(a)sbcglobal.net > > Ok...I went back to pharo0.1-10185dev08.12.1 and re-tried > pharo0.1-10196dev08.12.3 again, and they both die the same terrible > death when loading this update. > > I think it is shortly after a "recompiling" stage, then it hits a > "Loading" stage for a very long time. Finally, the debugger at the > bottom of the screen that I've never explored pops up and it looks > like a "days:hours:minutes:seconds:nanos:" flashes by repeatedly. > The window goes away, and shortly thereafter, so does pharo. > > Oh...I am running on Windows with the following VM from the system > menu: > > Squeak 3.10.7 (release) from Aug 22 2008 > Compiler: gcc 2.95.2 19991024 (release) > > Rob > > > On Wed, Jan 7, 2009 at 3:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > send it here for now. > pharo-dev should be pharo :) > > > > On Jan 7, 2009, at 9:56 PM, Rob Rothwell wrote: > > Interesting! I'll test that some more and make sure it is > reproducible, and then where do I post pharo dev image problems? > It's not really a pharo thing... > > Rob > > On Wed, Jan 7, 2009 at 3:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > hi rob > > I got not problem with the core image. > > Stef > > > On Jan 7, 2009, at 8:43 PM, Rob Rothwell wrote: > > Has anyone successfully loaded this from the System Update... menu > item? > > Whether starting from my own image, or a fresh dev08.12.3 image, it > eventully goes into debug mode at the bottom of the screen, and if > left on it's own, eventually just shuts down... > > Rob > > On Wed, Jan 7, 2009 at 1:06 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > - Issue 363: fix some traits issues (introduced by changes in > Metaclass and TestCase) > - Traits conflict marker methods stored in wrong cache > - Remove duplicated method in trait and class that uses it (in > collection tests) > - Issue 315: darker colors in diff dialog (thanks to Damien Pollet) > - Issue 342: Removing beginning capital letter of instance variables > (Alexandre Bergel) > - Make MC always display dependencies of a version in its summary text > - Issue: 101: fasterDayOfYear-brp.1 (Mantis 7156) > - Issue 102: better testPrintShowingDecimalPlaces > > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > 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 > > > >

1 0

Jan. 7, 2009

Hi all I published to the inbox some cool collection extension methods that we use all the time in Moose. flatCollect:, collectAsSet:, and groupedBy: http://code.google.com/p/pharo/issues/detail?id=432&colspec=ID%20Type%20Sta… I would like to have your feedback because we found them really useful in practice. Here are some examples: testFlatCollectArray "self debug: #testFlatCollectArray" self assert: ((#((1 2) (3 4) (5 3)) flatCollect: [ :each ]) = #(1 2 3 4 5 3)). self assert: ((#((1 2) (2 3) (1 3 4)) flatCollect: [:each]) = #(1 2 2 3 1 3 4)). self assert: ((#((1 2) (2 3) (1 3 4)) flatCollect: [:each| Set with: each]) = #(#(1 2) #(2 3) #(1 3 4))). testFlatCollectSet "self debug: #testFlatCollectSet" self assert: ((#((1 2) (1 2) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4) asSet). self assert: ((#() asSet flatCollect: [:each]) = #() asSet). self assert: ((#((1 2) () (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4) asSet). self assert: ((#((1 2) #((99)) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4 (99)) asSet). self assert: ((#((1 2) #(()) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4 ()) asSet). testGroupedByArray "self debug: #testGroupedByArray" | res | res := #(1 2 3 4 5) groupedBy: [:each | each odd]. self assert: (res at: true) = #(1 3 5). self assert: (res at: false) = #(2 4) testGroupedBy "self debug: #testGroupedBy" | res | res := #(1 2 3 4 5) asOrderedCollection groupedBy: [:each | each odd]. self assert: (res at: true) = #(1 3 5) asOrderedCollection. self assert: (res at: false) = #(2 4) asOrderedCollection

10 19