- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ODBC extension

by Schwab,Wilhelm K

Not that smart yet :) I figured I'd start here and suggestions like your would arise. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Tuesday, August 17, 2010 3:55 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] ODBC extension Why not comitting it in ODBC repository also? On Tue, Aug 17, 2010 at 9:52 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: I have a small group of packages that might be of interest to people porting code from Dolphin. By far the least controversial of these packages is a small addition to the ODBC packages. I have included a few things (e.g. #sqlCleanup) that I added to my Dolphin images and either needed or simply wanted in Pharo. Use them or ignore them as you see fit. Of perhaps general interest are methods to access schema information: #tables and #columnsForTable:owner:. The package is in the inbox: http://squeaksource.com/PharoInbox/DolphinCompatibility-ODBC-BillSchwab.2.m… Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2010

Re: [Pharo-project] ODBC extension

by Mariano Martinez Peck

Why not comitting it in ODBC repository also? On Tue, Aug 17, 2010 at 9:52 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I have a small group of packages that might be of interest to people > porting code from Dolphin. By far the least controversial of these packages > is a small addition to the ODBC packages. I have included a few things > (e.g. #sqlCleanup) that I added to my Dolphin images and either needed or > simply wanted in Pharo. Use them or ignore them as you see fit. > > Of perhaps general interest are methods to access schema information: > #tables and #columnsForTable:owner:. The package is in the inbox: > > > http://squeaksource.com/PharoInbox/DolphinCompatibility-ODBC-BillSchwab.2.m… > > Bill > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2010

Re: [Pharo-project] Fwd: break point

by Mariano Martinez Peck

On Tue, Aug 17, 2010 at 9:49 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > Yes... > > > > I was guilty of harvesting that for 3.7 or 3.6... (Squeak that is). > > nobody is guilty (we are not in religious stuff). > > > > > In the Old Browser, you have an entry "toggle break on entry". What this > > does is that it compiles a new version of the method (it uses a bit a > strange > > way of doing that using the old AST...). This version has a self break at > the beginning, > > yet points to the old source so you don't see it. > > > > Now the BreakPointmanager can remove all BreakPoints, all for a class and > things like > > that easily. it knows if there is one. CompiledMethod has #hasBreakpoint. > Setting breakpoints > > does not invalidate code (as opposed to self halt). > > > > So there is everything to make a nice UI for it... > > > > The model is a bit limited. Only break on entry, no probes and so on. But > it works. > > The limitations are mostly because everything else is hard to do with the > bad > > model we have in the current system of doing structural reflection below > method > > granularity... > > > > We should add a nice UI for it *and* soon we can do oh so much better > much easier :-) > > > May be lukas can get inspired and provide some break points support for OB > :) > For CodeHolder may be somebody else wants to have a look. > > But promise me that after putting a breakpoint I won't see my package as dirty ;) > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2010

[Pharo-project] ODBC extension

by Schwab,Wilhelm K

I have a small group of packages that might be of interest to people porting code from Dolphin. By far the least controversial of these packages is a small addition to the ODBC packages. I have included a few things (e.g. #sqlCleanup) that I added to my Dolphin images and either needed or simply wanted in Pharo. Use them or ignore them as you see fit. Of perhaps general interest are methods to access schema information: #tables and #columnsForTable:owner:. The package is in the inbox: http://squeaksource.com/PharoInbox/DolphinCompatibility-ODBC-BillSchwab.2.m… Bill

Aug. 17, 2010

Re: [Pharo-project] Fwd: break point

by StÃ©phane Ducasse

> Yes... > > I was guilty of harvesting that for 3.7 or 3.6... (Squeak that is). nobody is guilty (we are not in religious stuff). > > In the Old Browser, you have an entry "toggle break on entry". What this > does is that it compiles a new version of the method (it uses a bit a strange > way of doing that using the old AST...). This version has a self break at the beginning, > yet points to the old source so you don't see it. > > Now the BreakPointmanager can remove all BreakPoints, all for a class and things like > that easily. it knows if there is one. CompiledMethod has #hasBreakpoint. Setting breakpoints > does not invalidate code (as opposed to self halt). > > So there is everything to make a nice UI for it... > > The model is a bit limited. Only break on entry, no probes and so on. But it works. > The limitations are mostly because everything else is hard to do with the bad > model we have in the current system of doing structural reflection below method > granularity... > > We should add a nice UI for it *and* soon we can do oh so much better much easier :-) May be lukas can get inspired and provide some break points support for OB :) For CodeHolder may be somebody else wants to have a look. Stef

Aug. 17, 2010

[Pharo-project] why TextMorph and PluggableTextMorph are not

by StÃ©phane Ducasse

well in the same hierarchy? I like because I'm so naive about how the world could be :) Stef

Aug. 17, 2010

Re: [Pharo-project] Fwd: break point

by StÃ©phane Ducasse

Hi Marcus, > At least in Squeak 4.1. one can see the fact its break-pointed in the debugger because the method in the debugger is decompiled. > > > Now the BreakPointmanager can remove all BreakPoints, all for a class and things like > that easily. it knows if there is one. CompiledMethod has #hasBreakpoint. Setting breakpoints > does not invalidate code (as opposed to self halt). > > So there is everything to make a nice UI for it... > > One thing it badly needs is a "browse breakpointed methods" or "list breakpointed methods" > > The model is a bit limited. Only break on entry, no probes and so on. But it works. > The limitations are mostly because everything else is hard to do with the bad > model we have in the current system of doing structural reflection below method > granularity... > > We should add a nice UI for it *and* soon we can do oh so much better much easier :-) > > Tell me more, tell me more, was it love at first sight?? What are you cooking up? Opale compiler framework :) Opale is from cote d'opale and its lovely cap blanc nez and dunes :) http://a10.idata.over-blog.com/672x463/0/41/15/99/Entre-ciel-et-terre/Wissa… http://www.google.fr/images?client=safari&rls=en&q=cap+blanc+nez&oe=UTF-8&r… Now we just need the summer to get back in less than a year :) > > best > Eliot > > > Marcus > > > On Aug 17, 2010, at 8:56 PM, StÃ©phane Ducasse wrote: > > >> > >> In CodeHolder apparently there is support for breakpoint. > >> Does anybody know how this works? > >> Stef > >> > >> toggleBreakOnEntry > >> "Install or uninstall a halt-on-entry breakpoint" > >> > >> | selectedMethod | > >> self selectedClassOrMetaClass isNil ifTrue:[^self]. > >> selectedMethod := self selectedClassOrMetaClass >> self selectedMessageName. > >> selectedMethod hasBreakpoint > >> ifTrue: > >> [BreakpointManager unInstall: selectedMethod] > >> ifFalse: > >> [BreakpointManager > >> installInClass: self selectedClassOrMetaClass > >> selector: self selectedMessageName]. > >> > >> > >> > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > 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. 17, 2010

Re: [Pharo-project] Fwd: break point

by Eliot Miranda

Hi Marcus, On Tue, Aug 17, 2010 at 12:10 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Yes... > > I was guilty of harvesting that for 3.7 or 3.6... (Squeak that is). > > In the Old Browser, you have an entry "toggle break on entry". What this > does is that it compiles a new version of the method (it uses a bit a > strange > way of doing that using the old AST...). This version has a self break at > the beginning, > yet points to the old source so you don't see it. > At least in Squeak 4.1. one can see the fact its break-pointed in the debugger because the method in the debugger is decompiled. > > Now the BreakPointmanager can remove all BreakPoints, all for a class and > things like > that easily. it knows if there is one. CompiledMethod has #hasBreakpoint. > Setting breakpoints > does not invalidate code (as opposed to self halt). > > So there is everything to make a nice UI for it... > One thing it badly needs is a "browse breakpointed methods" or "list breakpointed methods" > > The model is a bit limited. Only break on entry, no probes and so on. But > it works. > The limitations are mostly because everything else is hard to do with the > bad > model we have in the current system of doing structural reflection below > method > granularity... > > We should add a nice UI for it *and* soon we can do oh so much better much > easier :-) > Tell me more, tell me more, was it love at first sight?? What are you cooking up? best Eliot > > Marcus > > > On Aug 17, 2010, at 8:56 PM, StÃ©phane Ducasse wrote: > > >> > >> In CodeHolder apparently there is support for breakpoint. > >> Does anybody know how this works? > >> Stef > >> > >> toggleBreakOnEntry > >> "Install or uninstall a halt-on-entry breakpoint" > >> > >> | selectedMethod | > >> self selectedClassOrMetaClass isNil ifTrue:[^self]. > >> selectedMethod := self selectedClassOrMetaClass >> self > selectedMessageName. > >> selectedMethod hasBreakpoint > >> ifTrue: > >> [BreakpointManager unInstall: selectedMethod] > >> ifFalse: > >> [BreakpointManager > >> installInClass: self > selectedClassOrMetaClass > >> selector: self selectedMessageName]. > >> > >> > >> > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2010

[Pharo-project] About changes

by StÃ©phane Ducasse

Hi guys I'm slowly going over the changes proposed by guillermo to remove ParagraphEditor (thansk guillermo). Now I think that this is important that we do not remove instance creation methods or method deprecated too fast. This is important that we let a chance to people to migrate. This is why we will remove the deprecate method of 1.1 when we will start 1.3 and not when we started 1.2. Stef

Aug. 17, 2010

Re: [Pharo-project] Load OB in Pharo 1.2

by StÃ©phane Ducasse

On Aug 17, 2010, at 8:28 PM, Lukas Renggli wrote: > Removing them is cool, but there should be a grace period where they > are deprecated. But how? We could let the subclass empty in this case (is it what you mean) but when we are doing refactoring like changing iv it may not work. We could not really let the classes in the system. I have the impression that having branch at the tool level is something that we cannot avoid. > Now I had to duplicate the whole class in OB with a > uniue name. ?? > > On Tuesday, August 17, 2010, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> Sorry, that was Stef and I at Camp Smalltalk. Did feel good to be rid of XYZPlus classes though ;-) >> >> Regards, Gary >> >> ----- Original Message ----- From: "Lukas Renggli" <renggli(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, August 17, 2010 7:07 PM >> Subject: Re: [Pharo-project] Load OB in Pharo 1.2 >> >> >> On Tuesday, August 17, 2010, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> On Aug 17, 2010, at 7:31 PM, Lukas Renggli wrote: >> >> >> Thanks Lukas. I wasn't who remove that class neither who didn't deprecated. >> I am just trying to start building Dev images from now...otherwise, we will >> have to wait a lot of time once the core is released. >> >> >> I think there must be a delay between the release of the core and the >> non-core images. I don't see how that can otherwise work. Of course it >> makes sense to have some incremental adaption already upfront ... >> >> >> Hmm... one thing is clear: I want to use Refactoring and especially the >> Code Critique tool on 1.2. So I need to somehow load it. >> >> >> Yeah that make sense, but I cannot maintain code that I can't use. >> >> Lukas >> >> >> >> (2 pages of philosophical ramblings deleted... I should start a blog..) >> >> Marcus >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(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 >> > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2010