August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo beta one-click somewhere?

by StÃ©phane Ducasse

:) but are you on mac? On Aug 26, 2009, at 1:08 PM, Janko MivÅ¡ek wrote: > Damien Cassou pravi: >> Janko MivÅ¡ek: >>> Is there any Pharo one-click around to adopt? Hopefully based on >>> latest >>> beta... > >> not yet sorry. Marcus, could you please build one? > > .. it would namely be nice to have a Pharo based one-click distro for > my tutorial on ESUG ... :) > > Janko > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 26, 2009

Re: [Pharo-project] new socket API

by StÃ©phane Ducasse

so what is the next step? stef On Aug 26, 2009, at 8:19 AM, Michael Rueger wrote: > Philippe Marschall wrote: > >> There's gotta be a better way to do this. >> >> The whole API with arrays where you have to know the index, ByteArray >> objects, integer flags and so forth seems like a blast from the past. > > > We could put some default behavior wrapper methods around this. > But this is really a discussion for squeak-dev, as the IPv6 > implementation originates from etoys/olpc. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 26, 2009

[Pharo-project] OB Package

by StÃ©phane Ducasse

Begin forwarded message: > From: David RÃ¶thlisberger <roethlis(a)iam.unibe.ch> > Date: August 26, 2009 12:01:54 PM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: Oscar Nierstrasz <oscar(a)iam.unibe.ch>, Lukas Renggli <renggli(a)iam.unibe.ch > >, Alexandre Bergel <abergel(a)dcc.uchile.cl> > Subject: Re: PBE and OB > > Hi, > > Lukas and me made it possible to load both versions of OmniBrowser > into the same image, the OB version of Colin and my OB version > providing the package browser. > As we said we duplicated the package browser OB packages to be able > to have both versions of OB in the same image. That solution is not > too nice, but in the short-term it should be fair enough until we > have real package support and can thus make the package browser more > efficient. > > To load the OB package browser packages, you need to load all > packages from this repo: > http://www.squeaksource.com/EnhancedOB/ > > You can then choose between OBSystemBrowser, O2SystemBrowser and > O2PackageBrowser. > > If you find any problems, let me know. > > Cheers, > David > > >> Excellent and thanks a lot you two. >> When you see that squeak is now doing all the same than us this is >> really important. >> I really appreciate your effort. >> On Aug 19, 2009, at 10:36 AM, David RÃ¶thlisberger wrote: >>> Hi, >>> >>> the package browser is again loadable also in latest Pharo by >>> executing 'ScriptLoader loadOBAlpha'. >>> This will load all required packages of OB as the package browser >>> needs it. This means that there will be a slighly different OB >>> code base in the image than what has been provided by Lukas' OB >>> version. >>> This also means that right now we can not use both browsers >>> (Lukas' category- and my package based) at the same time. >>> Lukas and me will work on making this possible on Monday. >>> >>> But note that you can use the system (category-based) and the >>> package browser based on the OB code base I maintained at the same >>> time; I think that's already good. I don't expect Lukas' version >>> of the system browser to be much faster. >>> >>> Cheers, >>> David >>> >>>> Excellent! >>>> I will continue to work on the package rewrite and like that for >>>> 1.1 we should have something. >>>> Stef >>>> On Aug 18, 2009, at 10:54 AM, Oscar Nierstrasz wrote: >>>>> >>>>> Hi Stef, >>>>> >>>>> I discussed with Lukas and David this morning. >>>>> >>>>> David will work this week (today?) to make sure that OB- >>>>> ENhancements can be loaded. >>>>> >>>>> Next week Monday, David and Lukas will sit together to create a >>>>> separate (renamed) package of David's OB, so the two browsers >>>>> can live in the same image, and the user can switch between >>>>> them. (Lukas estimates just an hour or so of work -- optimism >>>>> wins, I guess ;-) We can then include version this in the pharo- >>>>> dev image and in the PBE image. I will adapt the book to make >>>>> it clear that the user can switch between them. >>>>> >>>>> This is purely a stop-gap measure, as we eventually replace both >>>>> by a fast package browser (I guess) in the coming months. >>>>> >>>>> Sound ok to you? >>>>> >>>>> Cheers, >>>>> - on >>>>> >>>>> On Aug 17, 2009, at 17:05, StÃ©phane Ducasse wrote: >>>>> >>>>>> Yes now for pharo 1.0 it would be great if we could have >>>>>> fast lukas browser >>>>>> slow package browser >>>>>> all in the same image. >>>>>> >>>>>> can you check that with david? >>>>>> We do not care for speed now. >>>>>> and I will continue to work on the package but having a smooth >>>>>> integration/migration with/from the packageInfo >>>>>> >>>>> >>> >>> -- >>> ________________________________ >>> Mit freundlichen GrÃ¼ssen >>> David RÃ¶thlisberger >>> Doktorand Software Composition Group, IAM >>> UniversitÃ¤t Bern > > -- > ________________________________ > Mit freundlichen GrÃ¼ssen > David RÃ¶thlisberger > Doktorand Software Composition Group, IAM > UniversitÃ¤t Bern

Aug. 26, 2009

Re: [Pharo-project] Pharo beta one-click somewhere?

by Janko MivÅ¡ek

Damien Cassou pravi: > Janko MivÅ¡ek: >> Is there any Pharo one-click around to adopt? Hopefully based on latest >> beta... > not yet sorry. Marcus, could you please build one? .. it would namely be nice to have a Pharo based one-click distro for my tutorial on ESUG ... :) Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Aug. 26, 2009

Re: [Pharo-project] Pharo beta one-click somewhere?

by Damien Cassou

2009/8/26 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Is there any Pharo one-click around to adopt? Hopefully based on latest > beta... not yet sorry. Marcus, could you please build one? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 26, 2009

[Pharo-project] Pharo beta one-click somewhere?

by Janko MivÅ¡ek

Hi guys, Is there any Pharo one-click around to adopt? Hopefully based on latest beta... Thanks Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Aug. 26, 2009

Re: [Pharo-project] Native Windows

by Eagle Offshore

I've gotten a bit further but I'm finding it maddening in that quite often the whole thing will freeze for no apparent reason and with no clue as to what it is doing. I've just been working with the transcript. It launches in another window, it resizes properly, you can type into it, select all and delete, etc.... However I cannot get it to update in the background nicely (which is kind of the point for Transcript) although it updates just fine when in the foreground. I've implemented enough Morph protocol in DisplayHostWindow to allow it to serve as the root morph (although it actually holds a single morph that it keeps the same size as its window). The key method seems to be invalidRect: damageRect from: aMorph self redrawInBounds: damageRect. self forceToScreen: damageRect which, if I implement it, works briefly and then goes slower and slower and eventually hangs. I tried using CachingMorph as the root morph - this results in fullBounds based infinite recursion. Somehow I think this is at the root of Morphic's painful inefficiency. I think the layout/damage management code is trying to do too much. I've put about 40 hours into trying to track this - I'm taking a little break before diving in again. My head is quite bruised from banging it on that wall. -Todd Blanchard On Aug 25, 2009, at 1:24 AM, Henrik Johansen wrote: > Made a small experiment the other week of, sharing in case someone's > interested. > It renders an arbitrary SystemWindow in a ffenestri-window (on mac > at least) in the simplest way I could think of at least. (not > efficient (3MB or so per window), nor exactly pretty), but it makes > for a nice demo imo, even though the window is unresponsible to input. > Render update on resizing works, with a faux render loop instead of > real window resize event response :) > In theory you can do openInWorld on the same window, and manipulate > that, but I wouldn't recommend it, as the faux loop in the > workspace is in no way synchronized with World Drawing and you will > get DNU's after awhile. > > Install the changesets from ftp.smalltalkconsulting.com/experimental/Ffenestri/ > first, then the changeset in the attached zip. > Doit'ing the workspace in the .rtf should then open a Hierarchy > Browser on HierarchyBrowser, read comments there for more details :) > Should work on any SystemWindow instance, though actually getting to > an instance before it's opened can be surprisingly hard... > > Cheers, > Henry > > <FFenestriSystemWindowsExample.zip> > > On Aug 18, 2009, at 8:33 39PM, Eagle Offshore wrote: > >> What is the "canonical" window class in Pharo? I see SystemWindow >> has >> been subclassed and there's a separate builder for the other window >> that is otherwise a copy of the default builder. Where was that >> going? >> >> >> On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote: >> >>> I'll keep checking ,but, let me know when the basics are in and I'll >>> provide >>> support in Polymorph. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Igor Stasenko" <siguctua(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Tuesday, August 18, 2009 4:11 PM >>> Subject: Re: [Pharo-project] Native Windows >>> >>> >>>> 2009/8/18 Eagle Offshore <eagleoffshore(a)mac.com>: >>>>> I'm curious why you did a new plugin. Does the existing one not >>>>> work >>>>> on windows? >>>>> >>>> it works , but it duplicating a functionality which also present in >>>> core platform files: >>>> - creating a window >>>> - processing events >>>> >>>> so, the idea is to merge & unify all these bits into a single >>>> plugin >>>> and also, make an extended API for >>>> managing host windows. >>>> >>>>> I got the following from Bert on the state of the unix plugin: >>>>> >>>>> "The plugin functions are still stubbed out, so you cannot >>>>> actually >>>>> open a second window, yet. But at least the hairy part of the work >>>>> is >>>>> done - I implemented the dispatching between the HostWindow plugin >>>>> to >>>>> the various display modules. This is more complex than on the >>>>> other >>>>> platforms, because the unix VM so far supports X11, Quartz, >>>>> FrameBuffer, and Null display devices. But I did that part, now >>>>> someone can simply implement e.g. the X11 functions to have it >>>>> working >>>>> in Linux. The only function I actually implemented was changing >>>>> the >>>>> title of the main Squeak window (window index 1). >>>>> " >>>>> >>>>> -Todd Blanchard >>>>> >>>>> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: >>>>> >>>>>> 2009/8/18 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >>>>>>> Before you run too far down the let's change Morphic path you >>>>>>> should >>>>>>> check with Igor I'm sure he was off a year back trying to hack >>>>>>> Ffenestri into Morphic. >>>>>>> >>>>>> yes, yes i have an initial implementation of new hostwindows >>>>>> plugin >>>>>> which moves/separates the windowing stuff from core VM >>>>>> functionality. >>>>>> >>>>>> It then would be possible to build a VM which having no windowing >>>>>> support at all, and works as a console application. >>>>>> >>>>>> The problem with it, that i never did any windowing & event >>>>>> handling >>>>>> on X windows or MacOS, >>>>>> so its not so easy. I'm only hoping that my design fits well with >>>>>> other platforms, not only win32. >>>>>> >>>>>> I can publish the bits i'm done. Just say. >>>>>> I am swamped by another projects , so i don't know when i could >>>>>> find a >>>>>> time to finish it. :( >>>>>> >>>>>>> Tim and I gave that thought up when we considered there was 400 >>>>>>> or so >>>>>>> references to EventSenor & Display many of which had no >>>>>>> concept of >>>>>>> window ownership in mind. >>>>>> >>>>>> Yes, this is a bit of pain. >>>>>> My thought about it, is to keep sensor global, but >>>>>> replace all refs to Display to 'self display' message send. >>>>>> There are only a few methods which assigning new value to >>>>>> Display , >>>>>> which should be addressed separately. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >>>>>>> >>>>>>>> Thanks so much for sharing on this. >>>>>>>> >>>>>>>> There seems to be a few caches of stuff stashed in various >>>>>>>> places. >>>>>>>> None of it is exactly complete. I've taken the bulk of it from >>>>>>>> the http://source.impara.de/HostWindows >>>>>>>> and a bit from your experimental directory and looked at the >>>>>>>> plugins >>>>>>>> code in the VM tree and then just started trying to fix >>>>>>>> problems >>>>>>>> with event delivery. I'd like to pull it all together and >>>>>>>> make it >>>>>>>> coherent on Windows, OS X and Unix. >>>>>>>> >>>>>>>> Its really great that Pharo has integrated the HostMenus stuff >>>>>>>> - I >>>>>>>> think it would be cool to do HostWindows too. Once you >>>>>>>> eliminate >>>>>>>> having to emulate the look of the windows - most widget sets >>>>>>>> look >>>>>>>> pretty similar and I think morphic widgets inside of real >>>>>>>> windows >>>>>>>> would keep things from looking too weird while preserving the >>>>>>>> benefits of having our widgets in Smalltalk. >>>>>>>> >>>>>>>> Given Pharo's "take no prisoners" attitude, I think getting >>>>>>>> host >>>>>>>> windows working would allow a lot of really ugly code in >>>>>>>> PasteUpMorph and HandMorph to just go away. Event delivery in >>>>>>>> Morphic is just totally incomprehensible and I'm finding it is >>>>>>>> broken when a second window is introduced as the mouse >>>>>>>> coordinates >>>>>>>> seem to be delivered window relative. Its also really hard to >>>>>>>> work >>>>>>>> on because I keep junking images by making changes that wreck >>>>>>>> the >>>>>>>> UI. >>>>>>>> >>>>>>>> -Todd Blanchard >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> ================================================================ >>>>>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>>>>>> squeaker68882 >>>>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> ================================================================ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>>> project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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

Aug. 26, 2009

[Pharo-project] 3.11.4 Windows VM (was: Resource Directory support for Windows (VM 4.2.1Beta Window version ?

by Torsten Bergmann

Andreas wrote on Vm-dev list >Okay, 3.11.4 is in place now. Thanks for the new windows VM - will try it this evening. >Oh, and I finally remembered to add the version info to the VM. Cool! We should now also know the VM version from right clicking the EXE file (Properties -> Version). If one uses squeak to develop a windows based webserver app (Seaside or pier) this version information (vendor) should now also be displayed by personal firewalls when asking if you give permission to the executable. Before that it just displayed "squeak.exe" is requesting permission on port ... telling you that it comes from an anonymous vendor. So these few lines make life a little bit easier. Thanks! Bye Torsten -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

Aug. 26, 2009

Re: [Pharo-project] tallyIt nows trigger a complete profiling

by Damien Cassou

On Tue, Aug 25, 2009 at 5:16 PM, Alexandre Bergel<alexandre(a)bergel.eu> wrote: > This is much more useful I think. Before, it simply shows the time the > expression took to execute. Now you have the information about > different calls. > I put the tag Milestone-1.0 > http://code.google.com/p/pharo/issues/detail?id=1087 After beta new features should normally go to next Milestone => 1.1. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 26, 2009

Re: [Pharo-project] new socket API

by Michael Rueger

Philippe Marschall wrote: > There's gotta be a better way to do this. > > The whole API with arrays where you have to know the index, ByteArray > objects, integer flags and so forth seems like a blast from the past. We could put some default behavior wrapper methods around this. But this is really a discussion for squeak-dev, as the IPv6 implementation originates from etoys/olpc. Michael

Aug. 26, 2009