Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image
Hi Lukas,
I've installed ECompletion-lr.130.
It works brilliantly if I type: (' correctly skipping over ') at the end.
However if I type a single ' it doesn't add a closing ' - is this what
you're seeing?
Cheers
Nick
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HTTP client library in Pharo?
andrey do you know if they tests are failing also in squeak? Else what are the problems? Stef On Aug 1, 2010, at 3:03 AM, Andrey Larionov wrote: > I found WebClient resonably helpful. And in Pharo1.1 WebClient loaded > with Metacello passes all tests green on Linux. In more recent version > some test related to WebSockets are failed. > I found WebClient lack of multi-domain cookie support and response > encoding problems, but working on it right now. > > On Thu, Jul 29, 2010 at 20:06, Andrei Stebakov wrote: >> I've been trying to find a library for Pharo/Squeak which would handle >> GET/POST requests with the ability to manage cookies and deal with >> https servers. >> The HTTPSocket that's included in Pharo doesn't have cookies support. >> I tried to find any library that handles cookies and there came up >> CurlPlugin and SWHTTPClient. >> SWHTTPClient page has a broken link to the source code >> (http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f). >> CurlPlugin package for Win32 that I found on the main project page >> fails most of the tests and can't retrieve any http data. >> I also found WebClient/WebServer library at >> http://www.squeaksource.com/@QY3MLGU4hU3c8qcE/2xQek_iM which also >> fails most tests after installation. >> >> I wonder what people in smalltalk community are using when they need >> to do some web scraping when they need to keep some session in >> cookies? >> What would be the best library to invest time into (I am very new to >> Smalltalk)? >> >> Thank you, >> Andrei >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] String, ByteString and WideString
andrey can you post the mail to squeak since andreas read it more than this mailing-list I imagine. Stef On Aug 1, 2010, at 1:56 AM, Andrey Larionov wrote: > Working with WebClient i found what it lacks of non latin languages > support (for example Russian). During investigation i found, what for > streaming there used ByteString, which is custructed by calling String > class>>new:. All subclases of String by calling of this method > produces only ByteString instances. Also WriteStream>>contents > indirectly calls String class>>new:. So even you construct WideString > with #basicNew: calling > (WideString basicNew: size) writeStrem contents > produce only ByteString > > Is this a bug or there some workaround? > > Thanks. > > -- > Andrey Larionov > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image
> I've installed ECompletion-lr.130.
> It works brilliantly if I type: (' correctly skipping over ') at the end.
> However if I type a single ' it doesn't add a closing ' - is this what
> you're seeing?
Try ECompletion-lr.131, this fixes another set of bugs including the
one you reported.
The complexity of the code is quite horrible. Basically each of the
following cases has to be handled separately:
- selection? yes/no
- cursor at begin? yes/no
- cursor at end? yes/no
- open and close smart character the same? yes/no
- close character and next character in text the same? yes/no
Let me know if you find any more bugs.
Lukas
> Cheers
> Nick
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Lukas Renggli
www.lukas-renggli.ch
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CogVM as official Pharo VM?
On Jul 29, 2010, at 3:20 PM, Mariano Martinez Peck wrote: > I also agree with Janko idea. Image required changes where integrated in > PharoCore 1.2. not really I have to go over them once more but I'm busy with other simple fixes (= that other people could do but nobody dare to/have time to...) stef > We can start soon to build Dev images using that core, and, most importantly, > build a one click with Cog. > > Now the problem is.. > > 1) where to get the latest code from both, SVN and VMMaker. > 2) Compile and generate binaries for each platform > > Who can help us with this? > > The only binary I saw was the one Lukas did for Mac OS but I guess it should > be updated with latests fixes? > > Cheers > > Mariano > > On Thu, Jul 29, 2010 at 3:15 PM, David T. Lewis wrote: > This is very good advice. > > Dave > > On Thu, Jul 29, 2010 at 11:15:41AM +0200, Janko Miv??ek wrote: > > Hi guys, > > > > I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to: > > > > - encourage Cog usage and discovering all bugs and side effects, which > > will: > > - let the Cog become production ready more quickly, but it: > > - won't mislead people to consider Cog as production ready, because > > such unintential misleading can put Cog unfairly in a bad light. > > > > Best regards > > Janko > > > > On 29. 07. 2010 10:45, Mariano Martinez Peck wrote: > > > Hi folks. Hope Eliot is reading this thread. > > > > > > It is time to think in Pharo 1.2 and we need to discuss if we want to > > > have CogVM as the standard Pharo VM. > > > > > > Most of us have tried it and found it incredible fast. So it would be > > > very good to take advantage of it. But I think there are a couple of > > > things to be discussed: > > > > > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot > > > quotes: > > > "The Cog VM is a just-in-time compiler that currently supports only x86 > > > > > > No effort has been made to maintain 64-bit compatibility. Apologies, > > > this was unaffordable." > > > > > > So...how much important is this for us? do we care? and if we want to do > > > it, is it "doable" ? is it less doable than the normal squeak VM ? > > > > > > I really would like to have 64bits VM + 64bits images in a near > > > future...but hat's just my thoguhts. > > > > > > 2) The status of the external plugins. Are they working with Cog ? Not > > > only the "core plugings" but FFI, OSProcess (I read some problems with > > > it), TrueType, etc... > > > > > > 3) Is it stable for production use? For example, I read that with > > > seaside there are some crashes. > > > > > > 4) Depends on heroes. I never liked this idea. It has nothing to do with > > > Eliot. He is very cool and helpful. But I wonder, do we understand the > > > new VM and the changes? are we able to handle and fix it even without > > > eliot ? > > > > > > 5) Integration to VMMaker. I saw that they started to merge cog > > > (actually, I think only stack vm?) to the trunk of VMMaker. This is > > > really good news. I hope everything is there and merged. > > > > > > 6) Binaries. It seems the official released didn't come with binaries. > > > So we should compile it for each OS. > > > > > > > > > Ok..that's all my thoughts. I would really like to have a discussion > > > here and see what to do.grr you are all in holidays, aren't you? > > > hahah > > > > > > cheers > > > > > > Mariano > > > > > > > > > > > > ___ > > > Pharo-project mailing list > > > Pharo-project@lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > Janko Miv??ek > > Svetovalec za informatiko > > Eranova d.o.o. > > Ljubljana, Slovenija > > www.eranova.si > > tel: 01 514 22 55 > > faks: 01 514 22 56 > > gsm: 031 674 565 > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image
> > Try ECompletion-lr.131, this fixes another set of bugs including the > one you reported. That seems to have nailed it. I'll use it for real today and see if I spot anything else, but so far so good. Thanks again Nick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] cog-based image crashes on mac
lukas could you have a look at http://code.google.com/p/pharo/issues/detail?id=2579 because henrik mentioned that we missed something or could do it better. Stef On Jul 26, 2010, at 1:32 PM, Lukas Renggli wrote: The image I got is based on the sources from 27.06.2010. >>> >>> You may be missing some image-side changes. The CogVM was open sourced on >>> 20.06.2010. >> >> Actually, where should I get the complete image-side changes from? I have >> those prepared by Lukas a while ago. > > Yeah, these are the complete ones from the repository adapted to Pharo. > > Maybe these same socket related crashes that randomly appear with > Seaside images? > > nanosleep: Invalid argument > Exited with exit code: 1 > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] cog-based image crashes on mac
The changes I submitted are the ones of Eliot adapted to work in Pharo. I don't understand what Henrik writes, if he has something better he should attach the change. Lukas On Sunday, August 1, 2010, Stéphane Ducasse wrote: > lukas > > could you have a look at > http://code.google.com/p/pharo/issues/detail?id=2579 > because henrik mentioned that we missed something or could do it better. > > Stef > > > On Jul 26, 2010, at 1:32 PM, Lukas Renggli wrote: > > The image I got is based on the sources from 27.06.2010. You may be missing some image-side changes. The CogVM was open sourced on 20.06.2010. >>> >>> Actually, where should I get the complete image-side changes from? I have >>> those prepared by Lukas a while ago. >> >> Yeah, these are the complete ones from the repository adapted to Pharo. >> >> Maybe these same socket related crashes that randomly appear with >> Seaside images? >> >> nanosleep: Invalid argument >> Exited with exit code: 1 >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Make PackageOrganizer>>packageOfClass:ifNone: and PackageOrganizer>>packageOfMethod:ifNone: return the most specific package it can find
Hi I like the suggestion of daniel in Make PackageOrganizer>>packageOfClass:ifNone: and PackageOrganizer>>packageOfMethod:ifNone: return the most specific package it can find http://code.google.com/p/pharo/issues/detail?id=1752 Now I would like to have another pair of eyes on it. This is related to my idea of non overlapping package. Stef Fixed in: http://www.squeaksource.com/PharoInbox/PackageInfo-DanieRoux.35.mcz Took the fix from, and deprecated #mostSpecificPackageOfMethod:ifNone: and #mostSpecificPackageOfClass:ifNone: Background of problem: In theory it should not be possible for packages to overlap. Every class, and every method should belong to only one Category. In reality packaging bugs and other actions does cause packages to be created that overlap. An example in PharoCore, 10505 is this: (PackageOrganizer default packageNamed: 'Collections' ifAbsent: [ self error: 'hmm']) includesClass: Text. " true " (PackageOrganizer default packageNamed: 'Collections-Text' ifAbsent: [ self error: 'hmm']) includesClass: Text. " also true! " In the old implementation, #packageOfClass: would have returned the first category that matches. It will now return the more specific 'Collections-Text'. I suggest that #mostSpecificPackageOfClass* and #mostSpecificPackageOfMethod* methods be removed? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] cog-based image crashes on mac
Tx! Stef On Aug 1, 2010, at 10:40 AM, Lukas Renggli wrote: > The changes I submitted are the ones of Eliot adapted to work in > Pharo. I don't understand what Henrik writes, if he has something > better he should attach the change. > > Lukas > > On Sunday, August 1, 2010, Stéphane Ducasse wrote: >> lukas >> >> could you have a look at >> http://code.google.com/p/pharo/issues/detail?id=2579 >> because henrik mentioned that we missed something or could do it better. >> >> Stef >> >> >> On Jul 26, 2010, at 1:32 PM, Lukas Renggli wrote: >> >> The image I got is based on the sources from 27.06.2010. > > You may be missing some image-side changes. The CogVM was open sourced on > 20.06.2010. Actually, where should I get the complete image-side changes from? I have those prepared by Lukas a while ago. >>> >>> Yeah, these are the complete ones from the repository adapted to Pharo. >>> >>> Maybe these same socket related crashes that randomly appear with >>> Seaside images? >>> >>> nanosleep: Invalid argument >>> Exited with exit code: 1 >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > Lukas Renggli > www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How to remove Monticello?
Stephane suggested (MCWorkingCopy named: 'Monticello') unload. but the #named: message is unknown of MCWorkingCopy. Hilaire Le 30/07/2010 12:19, Hilaire Fernandes a écrit : > Dear all, > > I tried this: > > (MCPackage named: 'MonticelloGUI') unload. > (MCPackage named: 'MonticelloConfiguration') unload. > (MCPackage named: 'Monticello') unload. > > but the third line did not work. > > Any experiences to share on that topic? > > Thanks > > Hilaire ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Bug in OBHierarchyBrowser
http://code.google.com/p/pharo/issues/detail?id=2737. Lukas will accept the bug. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] List of possible actions for busy pharoers
hi guys I know that some of you would like to contribute but are busy, scared ... I spent three hours to go over the bug entries. Feel free to pick one and fix it: So now you can easily contribute. Just do it. Stef Some easy fixes: -- for the fixes based on squeak changed, it often requires to check the code and run pharo tests. http://code.google.com/p/pharo/issues/detail?id=2603 Issue 2603 isRunningCog http://code.google.com/p/pharo/issues/detail?id=2704 Issue 2704:Tests for broken withNoLineLongerThan: behavior. http://code.google.com/p/pharo/issues/detail?id=2693 http://code.google.com/p/pharo/issues/detail?id=2661 Issue 2661:File name correction for unix to allow http://code.google.com/p/pharo/issues/detail?id=2706 Issue 2706:Mirror primitive tests succeed on the Cog VMs. http://code.google.com/p/pharo/issues/detail?id=1746 Issue 1746: ReferenceStream>>readOnlyFileNamed: is missing http://code.google.com/p/pharo/issues/detail?id=1767 Issue 1767:Method Finder gives UndefinedObject error on search http://code.google.com/p/pharo/issues/detail?id=1765 Issue 1765: JPEGReadWriter>>#decompressionTest should be made into a Sunit Test http://code.google.com/p/pharo/issues/detail?id=2265 Issue 2265:to check MCWorkingCopyBrowser from Squeak http://code.google.com/p/pharo/issues/detail?id=2063 Issue 2063: NumberTest http://code.google.com/p/pharo/issues/detail?id=2266 Issue 2266: MessageNames selectorListIndex http://code.google.com/p/pharo/issues/detail?id=2176 Issue 2176: Integrated DirectoryEntry>>attributes http://code.google.com/p/pharo/issues/detail?id=2296 Issue 2296: Point>>closeTo http://code.google.com/p/pharo/issues/list?cursor=2573 Issue 2573: Make it possible to run cleanup non-interactively. http://code.google.com/p/pharo/issues/detail?id=2609 Issue 2609: getSystemAttribute: 2 -> documentPath Some important ones: -- http://code.google.com/p/pharo/issues/detail?id=2579 http://code.google.com/p/pharo/issues/detail?id=2698 http://code.google.com/p/pharo/issues/detail?id=2662 Issue 2662: value: primitives http://code.google.com/p/pharo/issues/detail?id=1801 Issue 1801:Rescue Sophie Undo framework http://code.google.com/p/pharo/issues/detail?id=2177 Issue 2177: Generalize stream protocol #readInto:startingAt:count: http://code.google.com/p/pharo/issues/detail?id=1921 Issue 1921: Class>>Binding Fix Issue 1981: Raising DuplicateError Exception in class builder http://code.google.com/p/pharo/issues/detail?id=1981 http://code.google.com/p/pharo/issues/detail?id=2146 Issue 2146:Fix SystemChangeNotification for traits. http://code.google.com/p/pharo/issues/detail?id=1899 Issue 1899: MethodDictionary improvement http://code.google.com/p/pharo/issues/detail?id=2315 Method Dictionary Compact protocol to investigate http://code.google.com/p/pharo/issues/list?cursor=2313 Issue 2313: HashedCollectionIntegrityTest http://code.google.com/p/pharo/issues/detail?id=2583 Issue 2583:COG - MessageTally Issue 2619: ignore vm parameters with nil value in MessageTally, so it can be used in Cog http://code.google.com/p/pharo/issues/detail?id=2584 COG- COG- LargeNegativeInteger to be compact at 5 http://code.google.com/p/pharo/issues/detail?id=2567 Issue 2567: evaluate the finalizers outside the protected block in WeakRegistry http://code.google.com/p/pharo/issues/detail?id=2564 Issue 2564: WeakKeyDictionary finalizeValue tests http://code.google.com/p/pharo/issues/list?cursor=2551 weakstructure http://code.google.com/p/pharo/issues/detail?id=2620 Issue 2620: BlockClosure asContext losing bound variable? http://code.google.com/p/pharo/issues/detail?id=2617 Issue 2617:Fix restart in blocks in debugger http://code.google.com/p/pharo/issues/detail?id=2618 Issue 2618:a bit faster DependentsArray >> #select: ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] next list of integration ready items
Marcus, adrian I will go over http://code.google.com/p/pharo/issues/detail?id=2169 http://code.google.com/p/pharo/issues/detail?id=2732 http://code.google.com/p/pharo/issues/detail?id=2727 http://code.google.com/p/pharo/issues/detail?id=1289 Issue 1289: Changing locale raises DNU http://code.google.com/p/pharo/issues/list?cursor=2721 sunit announcement http://code.google.com/p/pharo/issues/detail?id=1766 Issue 1766: #objectForDataStream: should be in Package System-Serialization http://code.google.com/p/pharo/issues/detail?id=2122 Issue 2122: superclassOrder: is defined on Changeset http://code.google.com/p/pharo/issues/detail?id=2205 pluugableTreeMorph http://code.google.com/p/pharo/issues/detail?id=2387 Issue 2387: Workspace http://code.google.com/p/pharo/issues/detail?id=2570 Issue 2570:Removed implicit conversion of DateAndTime equality-testing argument. http://code.google.com/p/pharo/issues/list?cursor=2364 file list menu cleaning http://code.google.com/p/pharo/issues/detail?id=2574 Issue 2574: flush obsolete PackageInfos and integrate them stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12072
12072 - - Issue 2727: Consistency by providing uppercase menu items in Tools menus (Part 2). Thanks Torsten. There are no such little fixes :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] List of possible actions for busy pharoers
this one is ready also: http://code.google.com/p/pharo/issues/detail?id=2733 On Sun, Aug 1, 2010 at 12:39 PM, Stéphane Ducasse wrote: > hi guys > > I know that some of you would like to contribute but are busy, scared ... > I spent three hours to go over the bug entries. Feel free to pick one and > fix it: > So now you can easily contribute. Just do it. > > Stef > > Some easy fixes: > -- > for the fixes based on squeak changed, it often requires to check the code > and run pharo tests. > > http://code.google.com/p/pharo/issues/detail?id=2603 Issue 2603 > isRunningCog > http://code.google.com/p/pharo/issues/detail?id=2704 Issue 2704: > Tests for broken withNoLineLongerThan: behavior. > http://code.google.com/p/pharo/issues/detail?id=2693 > http://code.google.com/p/pharo/issues/detail?id=2661 Issue 2661: > File name correction for unix to allow > http://code.google.com/p/pharo/issues/detail?id=2706 Issue 2706: > Mirror primitive tests succeed on the Cog VMs. > http://code.google.com/p/pharo/issues/detail?id=1746 Issue 1746: > ReferenceStream>>readOnlyFileNamed: is missing > http://code.google.com/p/pharo/issues/detail?id=1767 Issue 1767: > Method Finder gives UndefinedObject error on search > http://code.google.com/p/pharo/issues/detail?id=1765 Issue 1765: > JPEGReadWriter>>#decompressionTest should be made into a Sunit Test > http://code.google.com/p/pharo/issues/detail?id=2265 Issue 2265:to > check MCWorkingCopyBrowser from Squeak > http://code.google.com/p/pharo/issues/detail?id=2063 Issue 2063: > NumberTest > http://code.google.com/p/pharo/issues/detail?id=2266 Issue 2266: > MessageNames selectorListIndex > http://code.google.com/p/pharo/issues/detail?id=2176 Issue 2176: > Integrated DirectoryEntry>>attributes > http://code.google.com/p/pharo/issues/detail?id=2296 Issue 2296: > Point>>closeTo > http://code.google.com/p/pharo/issues/list?cursor=2573 Issue 2573: > Make it possible to run cleanup non-interactively. > http://code.google.com/p/pharo/issues/detail?id=2609 Issue 2609: > getSystemAttribute: 2 -> documentPath > > > Some important ones: > -- > http://code.google.com/p/pharo/issues/detail?id=2579 > http://code.google.com/p/pharo/issues/detail?id=2698 > http://code.google.com/p/pharo/issues/detail?id=2662 Issue 2662: value: > primitives > http://code.google.com/p/pharo/issues/detail?id=1801 Issue 1801: > Rescue Sophie Undo framework > http://code.google.com/p/pharo/issues/detail?id=2177 Issue 2177: > Generalize stream protocol #readInto:startingAt:count: > http://code.google.com/p/pharo/issues/detail?id=1921 Issue 1921: > Class>>Binding Fix > Issue 1981: Raising DuplicateError Exception in class builder > http://code.google.com/p/pharo/issues/detail?id=1981 > http://code.google.com/p/pharo/issues/detail?id=2146 Issue 2146: > Fix SystemChangeNotification for traits. > http://code.google.com/p/pharo/issues/detail?id=1899 Issue 1899: > MethodDictionary improvement > http://code.google.com/p/pharo/issues/detail?id=2315 Method Dictionary > Compact protocol to investigate > http://code.google.com/p/pharo/issues/list?cursor=2313 Issue 2313: > HashedCollectionIntegrityTest > http://code.google.com/p/pharo/issues/detail?id=2583 Issue 2583: > COG - MessageTally > Issue 2619: ignore vm parameters with nil value in > MessageTally, so it can be used in Cog > > http://code.google.com/p/pharo/issues/detail?id=2584 COG- COG- > LargeNegativeInteger to be compact at 5 > http://code.google.com/p/pharo/issues/detail?id=2567 Issue 2567: > evaluate the finalizers outside the protected block in WeakRegistry > http://code.google.com/p/pharo/issues/detail?id=2564 Issue 2564: > WeakKeyDictionary finalizeValue tests > http://code.google.com/p/pharo/issues/list?cursor=2551 weakstructure > http://code.google.com/p/pharo/issues/detail?id=2620 Issue 2620: > BlockClosure asContext losing bound variable? > http://code.google.com/p/pharo/issues/detail?id=2617 Issue 2617: > Fix restart in blocks in debugger > http://code.google.com/p/pharo/issues/detail?id=2618 Issue 2618:a > bit faster DependentsArray >> #select: > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in OBHierarchyBrowser
I fixed and closed the issue: Name: OB-Standard-lr.481 Author: lr Time: 1 August 2010, 3:33:14 pm UUID: 0fd4e1fa-323e-4ef5-b1ad-0ae74361a8f5 Ancestors: OB-Standard-lr.480 - Issue 2737: "Green hierarchy arrows" not working as expected in OBHierarchyBrowser On 1 August 2010 12:38, Max Leske wrote: > http://code.google.com/p/pharo/issues/detail?id=2737. > > Lukas will accept the bug. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HTTP client library in Pharo?
On 01.08.2010 09:39, Stéphane Ducasse wrote: > andrey > > do you know if they tests are failing also in squeak? > Else what are the problems? #squeakToUtf8, #utf8ToSqueak concatenating Strings and Integers. I sent a patch to Andreas, got WebSockets running in Seaside now :-) Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] String, ByteString and WideString
On 01.08.2010 01:56, Andrey Larionov wrote: > Working with WebClient i found what it lacks of non latin languages > support (for example Russian). During investigation i found, what for > streaming there used ByteString, which is custructed by calling String > class>>new:. All subclases of String by calling of this method > produces only ByteString instances. Also WriteStream>>contents > indirectly calls String class>>new:. So even you construct WideString > with #basicNew: calling > (WideString basicNew: size) writeStrem contents > produce only ByteString You probably want one of the MultiByteStreams and then set either the encoding or the converter. Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About overlapping packages :(
Stef, Coming from Dolphin, I have been surprised at how few packaging problems I (appear?) to have had in Pharo. One of the great terrors that enters the life of each Dolphin newbie is the dreaded "cyclic dependencies" error. The truth is that it is not a big deal: save the image and figure it out after you get some coffee. However, it sure seems awful the first few times the system refuses to save a package. Dolphin uses concrete packages; classes, methods and other objects belong to a package. Non-class objects (methods, view resources) by default belong to the same package as the associated class, but they can be placed elsewhere. Packages are explicitly created by the user and then are separately populated. I was generally shocked at how much work both Dolphin and Pharo users were willing to do in saving and loading packages. Over time, Dolphin became fairly adept at loading prerequisite packages, so things got easier. However, the readers here (for whom I have great respect) mystify me - or I am missing something about Monticello. I responded by "porting" a tool called Migrate that I wrote early on for Dolphin. Dolphin's package manager was fussy about loading things in the correct order, and I had no patience for loading 100+ packages with menu commands for each. Like I said, it improve over time to make Migrate less important in Dolphin, but something like it was essential to me in Pharo. Attached is a .mcz for Migrate-Core, relevant perhaps for two reasons. First, the fact that I exploit the ability to make a package called Migrate and then dash off a Migrate-Core that (hopefully) has just what I want to make public and nothing else. Second, it might give you some ideas about what a package system should do. My code is managed by a class called GatorAid that is derived from Migrate, and other users would presumably do the same thing: subclass, override a couple of methods, and follow the instructions (mostly in the Migrate class comment and some method comments), such as they are. In short, it helps look for code that I wrote and have not yet claimed ownership by telling Migrate I want to save it; it makes saving all packages I have asked it to save a one-step operation; it helps with building a new image. Perhaps the place to start is to have a quick look and to let me know if you have any questions. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Saturday, July 31, 2010 11:19 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About overlapping packages :( > sounds tricky. at the very least add a checker to a menu somewhere so > we can start to use it. I will do that. > You wouldn't need to that deeply integrate it > in the first instance... > > do you need to match the existing semantics exactly? I don't think > it's good that we can get into these situations. Perhaps we should > prevent them being able to be created in the first place, rather than > deal with them once they overlap. It will change the flow: we will not be able to create a new subpackage Foo-Core (if Foo is already created) , but will have to start delete the top package. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Migrate-Core-BillSchwab.1.mcz Description: Migrate-Core-BillSchwab.1.mcz ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HTTP client library in Pharo?
Cool! Thanks. I think that this is important to get good infrastructure. On Aug 1, 2010, at 3:43 PM, Philippe Marschall wrote: > On 01.08.2010 09:39, Stéphane Ducasse wrote: >> andrey >> >> do you know if they tests are failing also in squeak? >> Else what are the problems? > > #squeakToUtf8, #utf8ToSqueak concatenating Strings and Integers. > I sent a patch to Andreas, got WebSockets running in Seaside now :-) > > Cheers > Philippe > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About overlapping packages :(
Ok I will have a look. My new package implementation is fast and robust now I'm just bumping into fuzzy PackageInfo semantics. Stef On Aug 1, 2010, at 5:07 PM, Schwab,Wilhelm K wrote: > Stef, > > Coming from Dolphin, I have been surprised at how few packaging problems I > (appear?) to have had in Pharo. One of the great terrors that enters the > life of each Dolphin newbie is the dreaded "cyclic dependencies" error. The > truth is that it is not a big deal: save the image and figure it out after > you get some coffee. However, it sure seems awful the first few times the > system refuses to save a package. > > Dolphin uses concrete packages; classes, methods and other objects belong to > a package. Non-class objects (methods, view resources) by default belong to > the same package as the associated class, but they can be placed elsewhere. > Packages are explicitly created by the user and then are separately populated. > > I was generally shocked at how much work both Dolphin and Pharo users were > willing to do in saving and loading packages. Over time, Dolphin became > fairly adept at loading prerequisite packages, so things got easier. > However, the readers here (for whom I have great respect) mystify me - or I > am missing something about Monticello. I responded by "porting" a tool > called Migrate that I wrote early on for Dolphin. Dolphin's package manager > was fussy about loading things in the correct order, and I had no patience > for loading 100+ packages with menu commands for each. Like I said, it > improve over time to make Migrate less important in Dolphin, but something > like it was essential to me in Pharo. > > Attached is a .mcz for Migrate-Core, relevant perhaps for two reasons. > First, the fact that I exploit the ability to make a package called Migrate > and then dash off a Migrate-Core that (hopefully) has just what I want to > make public and nothing else. Second, it might give you some ideas about > what a package system should do. My code is managed by a class called > GatorAid that is derived from Migrate, and other users would presumably do > the same thing: subclass, override a couple of methods, and follow the > instructions (mostly in the Migrate class comment and some method comments), > such as they are. In short, it helps look for code that I wrote and have not > yet claimed ownership by telling Migrate I want to save it; it makes saving > all packages I have asked it to save a one-step operation; it helps with > building a new image. > > Perhaps the place to start is to have a quick look and to let me know if you > have any questions. > > Bill > > > > From: pharo-project-boun...@lists.gforge.inria.fr > [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse > [stephane.duca...@inria.fr] > Sent: Saturday, July 31, 2010 11:19 AM > To: Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] About overlapping packages :( > >> sounds tricky. at the very least add a checker to a menu somewhere so >> we can start to use it. > > I will do that. > >> You wouldn't need to that deeply integrate it >> in the first instance... >> >> do you need to match the existing semantics exactly? I don't think >> it's good that we can get into these situations. Perhaps we should >> prevent them being able to be created in the first place, rather than >> deal with them once they overlap. > > It will change the flow: we will not be able to create a new subpackage > Foo-Core (if Foo is already created) > , but will have to start delete the top package. > > Stef > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About overlapping packages :(
Stef, Are you perhaps running into problems with mapping category names to packages? The Dolphin approach to that is to avoid the topic: just present a list of packages and make the user pick one, after which the class/method/etc. is packaged. The resulting package system might then suffer the indignity of cyclic prerequisites, but there are ways to help the user fix that. I am not saying it is the correct solution (nor suggesting that it is not) - just reporting what Object Arts did. They got so many things *really* right that I default to trusting them. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Sunday, August 01, 2010 1:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About overlapping packages :( Ok I will have a look. My new package implementation is fast and robust now I'm just bumping into fuzzy PackageInfo semantics. Stef On Aug 1, 2010, at 5:07 PM, Schwab,Wilhelm K wrote: > Stef, > > Coming from Dolphin, I have been surprised at how few packaging problems I > (appear?) to have had in Pharo. One of the great terrors that enters the > life of each Dolphin newbie is the dreaded "cyclic dependencies" error. The > truth is that it is not a big deal: save the image and figure it out after > you get some coffee. However, it sure seems awful the first few times the > system refuses to save a package. > > Dolphin uses concrete packages; classes, methods and other objects belong to > a package. Non-class objects (methods, view resources) by default belong to > the same package as the associated class, but they can be placed elsewhere. > Packages are explicitly created by the user and then are separately populated. > > I was generally shocked at how much work both Dolphin and Pharo users were > willing to do in saving and loading packages. Over time, Dolphin became > fairly adept at loading prerequisite packages, so things got easier. > However, the readers here (for whom I have great respect) mystify me - or I > am missing something about Monticello. I responded by "porting" a tool > called Migrate that I wrote early on for Dolphin. Dolphin's package manager > was fussy about loading things in the correct order, and I had no patience > for loading 100+ packages with menu commands for each. Like I said, it > improve over time to make Migrate less important in Dolphin, but something > like it was essential to me in Pharo. > > Attached is a .mcz for Migrate-Core, relevant perhaps for two reasons. > First, the fact that I exploit the ability to make a package called Migrate > and then dash off a Migrate-Core that (hopefully) has just what I want to > make public and nothing else. Second, it might give you some ideas about > what a package system should do. My code is managed by a class called > GatorAid that is derived from Migrate, and other users would presumably do > the same thing: subclass, override a couple of methods, and follow the > instructions (mostly in the Migrate class comment and some method comments), > such as they are. In short, it helps look for code that I wrote and have not > yet claimed ownership by telling Migrate I want to save it; it makes saving > all packages I have asked it to save a one-step operation; it helps with > building a new image. > > Perhaps the place to start is to have a quick look and to let me know if you > have any questions. > > Bill > > > > From: pharo-project-boun...@lists.gforge.inria.fr > [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse > [stephane.duca...@inria.fr] > Sent: Saturday, July 31, 2010 11:19 AM > To: Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] About overlapping packages :( > >> sounds tricky. at the very least add a checker to a menu somewhere so >> we can start to use it. > > I will do that. > >> You wouldn't need to that deeply integrate it >> in the first instance... >> >> do you need to match the existing semantics exactly? I don't think >> it's good that we can get into these situations. Perhaps we should >> prevent them being able to be created in the first place, rather than >> deal with them once they overlap. > > It will change the flow: we will not be able to create a new subpackage > Foo-Core (if Foo is already created) > , but will have to start delete the top package. > > Stef > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo
Re: [Pharo-project] String, ByteString and WideString
maybe, but i'm thinking what (WideString basicNew: size) writeStrem contents should return WideString, not the ByteString On Sun, Aug 1, 2010 at 17:48, Philippe Marschall wrote: > On 01.08.2010 01:56, Andrey Larionov wrote: >> Working with WebClient i found what it lacks of non latin languages >> support (for example Russian). During investigation i found, what for >> streaming there used ByteString, which is custructed by calling String >> class>>new:. All subclases of String by calling of this method >> produces only ByteString instances. Also WriteStream>>contents >> indirectly calls String class>>new:. So even you construct WideString >> with #basicNew: calling >> (WideString basicNew: size) writeStrem contents >> produce only ByteString > > You probably want one of the MultiByteStreams and then set either the > encoding or the converter. > > Cheers > Philippe > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HTTP client library in Pharo?
Pharo1.1 dosn't contain this methods On Sun, Aug 1, 2010 at 21:36, Stéphane Ducasse wrote: > Cool! > Thanks. > I think that this is important to get good infrastructure. > > On Aug 1, 2010, at 3:43 PM, Philippe Marschall wrote: > >> On 01.08.2010 09:39, Stéphane Ducasse wrote: >>> andrey >>> >>> do you know if they tests are failing also in squeak? >>> Else what are the problems? >> >> #squeakToUtf8, #utf8ToSqueak concatenating Strings and Integers. >> I sent a patch to Andreas, got WebSockets running in Seaside now :-) >> >> Cheers >> Philippe >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About overlapping packages :(
> Stef, > > Are you perhaps running into problems with mapping category names to > packages? The Dolphin approach to that is to avoid the topic: just present a > list of packages and make the user pick one, after which the > class/method/etc. is packaged. The resulting package system might then > suffer the indignity of cyclic prerequisites, but there are ways to help the > user fix that. I am not saying it is the correct solution (nor suggesting > that it is not) - just reporting what Object Arts did. They got so many > things *really* right that I default to trusting them. This is what my implementation does. No magic matching. Just a list of classes and methods. Now if I do not support the * convention of packageinfo it means that we will not be able to load and save packages in a compatible form. We could do that and it would save me a lot of work. But people have to agree and understand the consequences. Of course we could do a MCPackageInfor specific loader that loads and convert MC packages. But this means that the packages will not be able to be used in Squeak. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12073
12073 - - Issue 1289: Changing locale raises DNU - test categories cleaning. Thanks alexandre. - Issue 2205: pluggable Tree Morph deselect behavior. Tx Laurent. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About overlapping packages :(
Hi Stef, I would go for first mirroring categories. Like this, Monticello would still work as expected, and we can just focus on improving the image based tools/concepts. Cheers, Doru On 1 Aug 2010, at 22:02, Stéphane Ducasse wrote: Stef, Are you perhaps running into problems with mapping category names to packages? The Dolphin approach to that is to avoid the topic: just present a list of packages and make the user pick one, after which the class/method/etc. is packaged. The resulting package system might then suffer the indignity of cyclic prerequisites, but there are ways to help the user fix that. I am not saying it is the correct solution (nor suggesting that it is not) - just reporting what Object Arts did. They got so many things *really* right that I default to trusting them. This is what my implementation does. No magic matching. Just a list of classes and methods. Now if I do not support the * convention of packageinfo it means that we will not be able to load and save packages in a compatible form. We could do that and it would save me a lot of work. But people have to agree and understand the consequences. Of course we could do a MCPackageInfor specific loader that loads and convert MC packages. But this means that the packages will not be able to be used in Squeak. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Sometimes the best solution is not the best solution." ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]
Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Thu, Jul 29, 2010 at 10:24 PM, Alexandre Bergel wrote: > > Maybe it's just me, or could we not add Announcement to the end of every > Announcement subclass name though? > > Like with the window announcement, I like them better as verbs describing > the event, f.ex. > > someAnnouncer on: TestStarted do: [] > > someAnnouncer on: TestEnded send: #x to: y > > Someone else vote for this? > I'm experimenting with Announcers on TestResult. What do you think about this syntax ? TestResult when: TestCaseStarts do: [:event | do some stuff ]. TestResult when: TestCaseEnds do: [:event | do some stuff ]. Laurent > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HTTP client library in Pharo?
On 01.08.2010 21:07, Andrey Larionov wrote: > Pharo1.1 dosn't contain this methods Yes, that's why the tests failed. Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] CampSmalltalk London tutorial
Hi Though it's been a couple of weeks since CampSmalltalk London, I've only just got round to creating a ConfigurationOfCampSmalltalkLondon which can be used to download the beginners tutorial Tim Mackinnon and I created. First some context. The beginners tutorial ran on the first day. We had 9 developers with a mixed background in Ruby/Java/C#/PHP etc. We started by going through the excellent ProfStef tutorial which we used as jump off point for frequent asides into the tools and code in Pharo. Next we gave them a simple exercise. You can download the code by grabbing ConfigurationOfCampSmalltalkLondon from http://www.squeaksource.com/MetacelloRepository.html and executing: (ConfigurationOfCampSmalltalkLondon project version: '1.0') load. The aim was to put into practice some of the concepts they'd learnt in the ProfStef tutorial - initially focusing on loops. The tutorial grabs live traffic information from the SE of the UK. Initially there is only one entry in the list viewable from their image at: http://localhost:8080/camp-smalltalk-london The first task was to change the code in CSLTransportInfo>>renderPage: to loop over the results and pass them to a custom renderer. Note we wanted to pass-on the joy of developing a web app in Smalltalk - the liveliness of the environment, code editing in the debugger etc - without first having to learn Seaside. So we hid the Seaside code behind some custom renderers. The second task was the change the renderer in CSLTransportInfo>>modelRenderer to be a CSLListItemRenderer. The task here was to notice the signature of the addItem method had changed and use the inspector and the browser to discover the relevant accessors on the result items. Finally they changed the renderer again for a CSLMapRenderer and went through a similar routine to step two, though this time the result of their labours was to transform a boring list into an impressive map - graphically showing traffic incidents. Those who were more advanced could then filter the results to look at say only incidents along particular roads etc. The tutorial session seemed to be well received. I don't know if anyone out there is planning to run an introduction to Smalltalk - if so they are more than welcome to use the code. All feedback gratefully received. Nick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Unloading oCompletion to use eCompletion
Hi Guys - I tried using Lucas' hudson build of the seaside image which has eCompletion enabled in it by default - and I have to say I found it much snappier and it just seems to work better somehow (take this with a pinch of salt - as a Dolphin user I find so many things strange in Pharo - but I keep plugging away trying to convert myself to a place where I feel comfortable). However I do like the MercuryPanel in the standard Pharo/Seaside image - and as I don't know/understand what gets loaded into each image, I thought I would try just unloading oCompletion and loading in eCompletion in the standar seaside 3.0RC image instead. Anyway - I get an error when I do this (things are registered to receive events, and then when they start to unload things aren't there to receive the events and so you get a walkback). I logged a bug report for this - but did eventually manage to unload oCompletion manually. However when I then loaded eCompletion it seemed that certain classes weren't being picked up, so I had to resave a few methods in the debugger to get it going (is there a way to just refresh an image to make sure all classes are up to date?). Is there an easier way to load/unload oCompletion and eCompletion? Tim ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] cog-based image crashes on mac
On Aug 1, 2010, at 10:40 53AM, Lukas Renggli wrote: > The changes I submitted are the ones of Eliot adapted to work in > Pharo. I don't understand what Henrik writes, if he has something > better he should attach the change. > > Lukas Not better, just simpler code. If I'm not mistaken, if primitive 38 fails in Cog, so will primitive 60. Primitive 38 will always fail in a non-cog vm. The failure handling code after the ec == nil check is the same in Float>>basicAt: and Object basicAt: Thus, writing Float>>basicAt: index ^super basicAt: index would yield the exact same result, with the difference that you will have an extra primtive 60 failure in Cog vm's, an ec = nil check less in non-cog VM's, and no duplication of the fallback-handling code. The alternate code was attached, in issue 2581. Cheers, Henry > > On Sunday, August 1, 2010, Stéphane Ducasse wrote: >> lukas >> >> could you have a look at >> http://code.google.com/p/pharo/issues/detail?id=2579 >> because henrik mentioned that we missed something or could do it better. >> >> Stef >> >> >> On Jul 26, 2010, at 1:32 PM, Lukas Renggli wrote: >> >> The image I got is based on the sources from 27.06.2010. > > You may be missing some image-side changes. The CogVM was open sourced on > 20.06.2010. Actually, where should I get the complete image-side changes from? I have those prepared by Lukas a while ago. >>> >>> Yeah, these are the complete ones from the repository adapted to Pharo. >>> >>> Maybe these same socket related crashes that randomly appear with >>> Seaside images? >>> >>> nanosleep: Invalid argument >>> Exited with exit code: 1 >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > Lukas Renggli > www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] ProgressDisplay package released
I recently released the first draft of my package ProgressDisplay to SqueakSource. It is like SystemProgressMorph et. al. but with a lot of bells and whistles added. It is not a suitable replacement for SystemProgressMorph though because it is too large and specific for that. SystemProgressMorph could be made a subclass of one of its classes though. It is designed largely to meet my specific needs but since it's MIT anyone may use it, steal components, or move components of it to Squeak/Pharo. It has a utility class category with useful classes for things like array permutation generation and array multiset permutation generation, numeric partitioning of a number, and a class RangeList (which I will be expanding upon later). All of these classes will be removed when the package meant to contain them is ready (not soon). There are also a number of utility methods that could be stolen or put into Squeak/Pharo proper. It probably has lots of bugs, so bug reports appreciated. Comments on its function, design, and implementation most welcome. Proposals for improvements or extensions will be considered but no promises. If you need access to make changes let me know. If Levente Uzonyi likes it but feels compelled to rewrite it completely from scratch, thats okay too. :-) ONE OF MY REASONS FOR RELEASING IT IS BECAUSE OF A BUG I COULD NOT FIX. It is supposed to be possible to turn on the ability to catch user interrupts but when this feature is turned on and an interrupt generated while the progress bar is displayed the interrupt is caught but not processed until the progress bar closes. :-( Of course the interrupt was meant to be processed immediately. If anyone can tell me how to fix this bug (or better still send me the code or add the code to the package) that would be great! Regards, Ralph Boland -- Quantum Theory cannot save us from the tyranny of a deterministic universe but it does give God something to do ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CampSmalltalk London tutorial
> ConfigurationOfCampSmalltalkLondon I would recommend to change the name of the configuration. From its name, I cannot figure out what it is about. Why not ConfigurationOfPharoAndSeasideTutorial Cheers, Alexandre > First some context. The beginners tutorial ran on the first day. We had 9 > developers with a mixed background in Ruby/Java/C#/PHP etc. We started by > going through the excellent ProfStef tutorial which we used as jump off point > for frequent asides into the tools and code in Pharo. > > Next we gave them a simple exercise. You can download the code by grabbing > ConfigurationOfCampSmalltalkLondon from > http://www.squeaksource.com/MetacelloRepository.html and executing: > > (ConfigurationOfCampSmalltalkLondon project version: '1.0') load. > > The aim was to put into practice some of the concepts they'd learnt in the > ProfStef tutorial - initially focusing on loops. The tutorial grabs live > traffic information from the SE of the UK. Initially there is only one entry > in the list viewable from their image at: > http://localhost:8080/camp-smalltalk-london > > The first task was to change the code in CSLTransportInfo>>renderPage: to > loop over the results and pass them to a custom renderer. Note we wanted to > pass-on the joy of developing a web app in Smalltalk - the liveliness of the > environment, code editing in the debugger etc - without first having to learn > Seaside. So we hid the Seaside code behind some custom renderers. > > The second task was the change the renderer in > CSLTransportInfo>>modelRenderer to be a CSLListItemRenderer. The task here > was to notice the signature of the addItem method had changed and use the > inspector and the browser to discover the relevant accessors on the result > items. > > Finally they changed the renderer again for a CSLMapRenderer and went through > a similar routine to step two, though this time the result of their labours > was to transform a boring list into an impressive map - graphically showing > traffic incidents. > > Those who were more advanced could then filter the results to look at say > only incidents along particular roads etc. > > The tutorial session seemed to be well received. I don't know if anyone out > there is planning to run an introduction to Smalltalk - if so they are more > than welcome to use the code. > > All feedback gratefully received. > > Nick > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image
2010/8/1 Nick Ager : >> Try ECompletion-lr.131, this fixes another set of bugs including the >> one you reported. > > That seems to have nailed it. I'll use it for real today and see if I spot > anything else, but so far so good. > Thanks again Where can I find those changes - my Monticello browser pointing at squeaksource can only see up to ECompletion-lr.122 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
