October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Newbie question: Connection to SQLite DB

by nullPointer

Mariano Martinez Peck wrote: > > > You need the opendbx and sqlite libraries. > Everything is explained here: > http://www.squeakdbx.org/Compiling%20and%20installing%20OpenDBX > > or here http://www.squeakdbx.org/Compiling%20for%20different%20backends > > glups! that must be the problem :| I did install the binary sqlite on OS ( in the bin folder, correct? ) but not the OpenDBX. Anything Sqlite3 project donÂ´t work of that way. I will try with SqueakDBX and installing OpenDBX before. As you can see IÂ´m very newbie on that things :( Thanks. -- View this message in context: http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 4, 2010

Re: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm))

by Igor Stasenko

On 4 October 2010 11:59, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote: > >> For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. Â The calls need to block their calling Process and let the other Processes run as though nothing is happening. >> > You're right. > Another option is having a multi-threaded VM. Eliot seem to work on it. > So far we're working on cleaning up the design of basic functionalities before going on. > Then, we'll try to find a workaround for non-blocking calls. > All ideas are welcome :-) > There are two ways. Use sockets in blocking mode or in non-blocking mode. In both variants its possible to not block VM thread during the call(s), but depending on socket's mode, implementation will be different. i think it would be cool to have non-blocking socket at language side (i.e. doing socket calls does not blocks VM as well as smalltalk Process which made it). What could block the process , is putting it on wait , till socket's state change (ready for write, connected, closed etc). Now i think that with such approach you don't even need generic non-blocking FFI callout mechanism. You just need to run extra native thread(s), which periodically polls the socket(s) state and signals its semaphores accordingly. > BTW, some people (you included) proposed to help for the Ocean project. > Luc and I want to thank you and we are happy that others are willing to help. > We thought about the best way to integrate others help. > Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. > So, we all can work on solid foudations. > > Noury > > > > _______________________________________________ > 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.

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Lukas Renggli

> Ok, let's summarize: If an error occurs, the handler block is not > evaluated, but attached to a new exception, that exception is raised. > Then, the caller catches that exception, retrieves the handler block, > does some more ballyhoo, and then runs the handler block. Yes, the block mostly contains some code to that allows the user to fix the problem (like to show all references of a class to be removed, etc.). > And you get invited to this construction by these methods in > RBAbstractCondition: > > errorBlock > Â Â Â Â ^self errorBlockFor: false > > errorBlockFor: aBoolean > Â Â Â Â ^nil These methods (and subclass implementations) are used to retrieve the right block that caused the composite condition to fail. > We can clean it up on the next sprint, if you want :) The implementation in RBCondition is fine, the problem is more the way how exceptions are used to pass the values. This mainly stems from the fact that exceptions evolved over the past 15 years and are no longer the same as the signals that were used when the refactoring code was originally written. Now of course it is difficult to change this code because there are various users out there that depend on it, e.g. OB, RefactoringBrowser, SmaCC, ... Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Niko Schwarz

Ok, let's summarize: If an error occurs, the handler block is not evaluated, but attached to a new exception, that exception is raised. Then, the caller catches that exception, retrieves the handler block, does some more ballyhoo, and then runs the handler block. And you get invited to this construction by these methods in RBAbstractCondition: errorBlock ^self errorBlockFor: false errorBlockFor: aBoolean ^nil We can clean it up on the next sprint, if you want :) Niko On Mon, Oct 4, 2010 at 4:14 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > The tool that triggers the refactoring, e.g. ORCommand>>#handleError: > > Ok, the code is quite ugly, but this is how the original refactoring > browser implemented it. > > On 4 October 2010 16:06, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >> Ok, help me out, how is that block ever invoked? The above code >> snippet just appends the block as a parameter to an exception, which >> looks just funny. >> >> Niko >> >> On Mon, Oct 4, 2010 at 3:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> See for senders of #errorBlock:, e.g. >>> PushDownInstanceVariableRefactoring, RemoveClassRefactoring or >>> RemoveInstanceRefactoring. >>> >>> On 4 October 2010 15:40, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> This is used to validate the preconditions of refactorings and inform >>>> the user about any mismatches. >>>> >>>> It should better not be removed. >>>> >>>> Lukas >>>> >>>> On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >>>>> Hi, >>>>> >>>>> The RB refactorings do some obscure dance around an errorBlock, which >>>>> is always nil, as far as I can see. As I was trying to supply a >>>>> non-nil error block, I was astonished to find out that even if it >>>>> isn't nil, it won't be executed. Here's the relevant snippets: >>>>> >>>>> checkPreconditions >>>>> Â Â Â Â | conditions block | >>>>> Â Â Â Â conditions := self preconditions. >>>>> Â Â Â Â conditions check >>>>> Â Â Â Â Â Â Â Â ifFalse: >>>>> Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. >>>>> Â Â Â Â Â Â Â Â Â Â Â Â block notNil >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] >>>>> >>>>> refactoringError: aString with: aBlock >>>>> Â Â Â Â ^ RefactoringError signal: aString with: aBlock >>>>> >>>>> I can't imagine how that could help anyone. I suggest either removing >>>>> the errorBlock, or turning it into a good old instance variable, and >>>>> running it in case of an error. >>>>> >>>>> Cheers, >>>>> >>>>> Niko >>>>> >>>>> -- >>>>> http://scg.unibe.ch/staff/Schwarz >>>>> twitter.com/nes1983 >>>>> Tel: +41 076 235 8683 >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> 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 > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Oct. 4, 2010

Re: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm))

by Schwab,Wilhelm K

Noury, I am very interested in seeing this done well. At a minimum, I'll give the result some serious abuse. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Noury Bouraqadi [bouraqadi(a)gmail.com] Sent: Monday, October 04, 2010 4:59 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)) On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote: > For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening. > You're right. Another option is having a multi-threaded VM. Eliot seem to work on it. So far we're working on cleaning up the design of basic functionalities before going on. Then, we'll try to find a workaround for non-blocking calls. All ideas are welcome :-) BTW, some people (you included) proposed to help for the Ocean project. Luc and I want to thank you and we are happy that others are willing to help. We thought about the best way to integrate others help. Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. So, we all can work on solid foudations. Noury _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

[Pharo-project] Soap Webservices for pharo

by Guillermo Polito

http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html So, we have some tasks now: - put it in squeaksource - test it in pharo - build a metacello config - document it? Any help is really appreciated, since I don't have too much time. Cheers, Guille ---------- Forwarded message ---------- From: Masashi Umezawa <umejava(a)mars.dti.ne.jp> Date: Mon, Oct 4, 2010 at 8:46 AM Subject: Re: About SoapOpera and SoapCore To: Guillermo Polito <guillermopolito(a)gmail.com> Hi Guillermo, I am happy to hear that SoapOpera and SoapCore would be useful for your projects. Please feel free to reuse my Soap stuff. Recently I do not have enough time to upgrade those packages. So I really appreciate your offer. I hope SoapOpera and SoapCore will start growing again! Best regards, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi! > > My name's Guillermo and I'm from Argentina. I'm participating in the pharo > project (www.pharo-project.org) and I would love to integrate your soap > package into our available packages :). > I was wandering if you let us put it into squeaksource ( www.squeaksource.com) > and mantain it for our use, because pharo is growing very quickly and it > needs this kind of really cool stuff :). Of course we will keep the MIT > license. > > Thank you for your time and sorry for bothering :P! > Guille --- [:masashi | ^umezawa]

Oct. 4, 2010

Re: [Pharo-project] do we need handleDisabledKey:

by Gary Chambers

Similar, but reworked to fit in with TextEditor>>disptachOn: style of handling. Regards, Gary ----- Original Message ----- From: Guillermo Polito To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, October 04, 2010 1:26 PM Subject: Re: [Pharo-project] do we need handleDisabledKey: So as a first approach, we should use the ParagraphEditor #handleDisabledKey: behavior. Should we? Cheers, Guille On Mon, Oct 4, 2010 at 7:29 AM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: Well, the short answer is "yes" if we want the (previously requested long ago) features of being able to copy text, browse classes etc. from selections in disabled text. Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, October 04, 2010 11:17 AM Subject: Re: [Pharo-project] do we need handleDisabledKey: Catching up on emails after being away... will check once software update completes... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, September 24, 2010 7:01 PM Subject: [Pharo-project] do we need handleDisabledKey: hi gary do we need handleDisabledKey: because this is not defined on the new editorHierarchy? http://code.google.com/p/pharo/issues/detail?id=3003 Stef _______________________________________________ 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

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Lukas Renggli

The tool that triggers the refactoring, e.g. ORCommand>>#handleError: Ok, the code is quite ugly, but this is how the original refactoring browser implemented it. On 4 October 2010 16:06, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: > Ok, help me out, how is that block ever invoked? The above code > snippet just appends the block as a parameter to an exception, which > looks just funny. > > Niko > > On Mon, Oct 4, 2010 at 3:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> See for senders of #errorBlock:, e.g. >> PushDownInstanceVariableRefactoring, RemoveClassRefactoring or >> RemoveInstanceRefactoring. >> >> On 4 October 2010 15:40, Lukas Renggli <renggli(a)gmail.com> wrote: >>> This is used to validate the preconditions of refactorings and inform >>> the user about any mismatches. >>> >>> It should better not be removed. >>> >>> Lukas >>> >>> On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >>>> Hi, >>>> >>>> The RB refactorings do some obscure dance around an errorBlock, which >>>> is always nil, as far as I can see. As I was trying to supply a >>>> non-nil error block, I was astonished to find out that even if it >>>> isn't nil, it won't be executed. Here's the relevant snippets: >>>> >>>> checkPreconditions >>>> Â Â Â Â | conditions block | >>>> Â Â Â Â conditions := self preconditions. >>>> Â Â Â Â conditions check >>>> Â Â Â Â Â Â Â Â ifFalse: >>>> Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. >>>> Â Â Â Â Â Â Â Â Â Â Â Â block notNil >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] >>>> >>>> refactoringError: aString with: aBlock >>>> Â Â Â Â ^ RefactoringError signal: aString with: aBlock >>>> >>>> I can't imagine how that could help anyone. I suggest either removing >>>> the errorBlock, or turning it into a good old instance variable, and >>>> running it in case of an error. >>>> >>>> Cheers, >>>> >>>> Niko >>>> >>>> -- >>>> http://scg.unibe.ch/staff/Schwarz >>>> twitter.com/nes1983 >>>> Tel: +41 076 235 8683 >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> 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 >> > > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > _______________________________________________ > 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

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Niko Schwarz

Ok, help me out, how is that block ever invoked? The above code snippet just appends the block as a parameter to an exception, which looks just funny. Niko On Mon, Oct 4, 2010 at 3:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > See for senders of #errorBlock:, e.g. > PushDownInstanceVariableRefactoring, RemoveClassRefactoring or > RemoveInstanceRefactoring. > > On 4 October 2010 15:40, Lukas Renggli <renggli(a)gmail.com> wrote: >> This is used to validate the preconditions of refactorings and inform >> the user about any mismatches. >> >> It should better not be removed. >> >> Lukas >> >> On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >>> Hi, >>> >>> The RB refactorings do some obscure dance around an errorBlock, which >>> is always nil, as far as I can see. As I was trying to supply a >>> non-nil error block, I was astonished to find out that even if it >>> isn't nil, it won't be executed. Here's the relevant snippets: >>> >>> checkPreconditions >>> Â Â Â Â | conditions block | >>> Â Â Â Â conditions := self preconditions. >>> Â Â Â Â conditions check >>> Â Â Â Â Â Â Â Â ifFalse: >>> Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. >>> Â Â Â Â Â Â Â Â Â Â Â Â block notNil >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] >>> >>> refactoringError: aString with: aBlock >>> Â Â Â Â ^ RefactoringError signal: aString with: aBlock >>> >>> I can't imagine how that could help anyone. I suggest either removing >>> the errorBlock, or turning it into a good old instance variable, and >>> running it in case of an error. >>> >>> Cheers, >>> >>> Niko >>> >>> -- >>> http://scg.unibe.ch/staff/Schwarz >>> twitter.com/nes1983 >>> Tel: +41 076 235 8683 >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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 > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Lukas Renggli

See for senders of #errorBlock:, e.g. PushDownInstanceVariableRefactoring, RemoveClassRefactoring or RemoveInstanceRefactoring. On 4 October 2010 15:40, Lukas Renggli <renggli(a)gmail.com> wrote: > This is used to validate the preconditions of refactorings and inform > the user about any mismatches. > > It should better not be removed. > > Lukas > > On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >> Hi, >> >> The RB refactorings do some obscure dance around an errorBlock, which >> is always nil, as far as I can see. As I was trying to supply a >> non-nil error block, I was astonished to find out that even if it >> isn't nil, it won't be executed. Here's the relevant snippets: >> >> checkPreconditions >> Â Â Â Â | conditions block | >> Â Â Â Â conditions := self preconditions. >> Â Â Â Â conditions check >> Â Â Â Â Â Â Â Â ifFalse: >> Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. >> Â Â Â Â Â Â Â Â Â Â Â Â block notNil >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] >> >> refactoringError: aString with: aBlock >> Â Â Â Â ^ RefactoringError signal: aString with: aBlock >> >> I can't imagine how that could help anyone. I suggest either removing >> the errorBlock, or turning it into a good old instance variable, and >> running it in case of an error. >> >> Cheers, >> >> Niko >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Lukas Renggli

This is used to validate the preconditions of refactorings and inform the user about any mismatches. It should better not be removed. Lukas On 4 October 2010 15:36, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: > Hi, > > The RB refactorings do some obscure dance around an errorBlock, which > is always nil, as far as I can see. As I was trying to supply a > non-nil error block, I was astonished to find out that even if it > isn't nil, it won't be executed. Here's the relevant snippets: > > checkPreconditions > Â Â Â Â | conditions block | > Â Â Â Â conditions := self preconditions. > Â Â Â Â conditions check > Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â [block := conditions errorBlock. > Â Â Â Â Â Â Â Â Â Â Â Â block notNil > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self refactoringError: conditions errorString with: block] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self refactoringError: conditions errorString]] > > refactoringError: aString with: aBlock > Â Â Â Â ^ RefactoringError signal: aString with: aBlock > > I can't imagine how that could help anyone. I suggest either removing > the errorBlock, or turning it into a good old instance variable, and > running it in case of an error. > > Cheers, > > Niko > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > _______________________________________________ > 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

Oct. 4, 2010

[Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by Niko Schwarz

Hi, The RB refactorings do some obscure dance around an errorBlock, which is always nil, as far as I can see. As I was trying to supply a non-nil error block, I was astonished to find out that even if it isn't nil, it won't be executed. Here's the relevant snippets: checkPreconditions | conditions block | conditions := self preconditions. conditions check ifFalse: [block := conditions errorBlock. block notNil ifTrue: [self refactoringError: conditions errorString with: block] ifFalse: [self refactoringError: conditions errorString]] refactoringError: aString with: aBlock ^ RefactoringError signal: aString with: aBlock I can't imagine how that could help anyone. I suggest either removing the errorBlock, or turning it into a good old instance variable, and running it in case of an error. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Oct. 4, 2010

Re: [Pharo-project] XMLRPC Project - Progress Report

by Sven Van Caekenberghe

StÃ©phane, On 03 Oct 2010, at 19:24, StÃ©phane Ducasse wrote: > Tell us when pharo core can be a user. > Because we want to clean the mess. I know you are anxious to do so, and it will happen one day, for sure. There is still some technical work to do, but the most important thing is that we need as much users as possible to shake out the bugs. The code has to prove itself for others (with different encodings/languages/networks). Sven PS: As I said before, I am using it myself everyday, working in a Pharo 1.1 image were all HTTPSocket stuff is routed to Zn, so far so good. I also replaced all my other HTTP client uses by using Zn directly, and that works well too. We're getting closer.

Oct. 4, 2010

Re: [Pharo-project] Newbie question: Connection to SQLite DB

by Mariano Martinez Peck

On Mon, Oct 4, 2010 at 2:07 PM, nullPointer <epicfan(a)gmail.com> wrote: > > IÂ´m cannot connect a sample SQLite DB. IÂ´m sure need some steps but I donÂ´t > know exactly. > Really I have alway problems when I try execute some external to Smalltalk > image. Exists a document with global information of that? > > I did install SQueakDBX (with problems for #and:and:and: deprecated method > of boolean), How did you install SqueakDBX? Becasue this should not happen. Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSqueakDBX'; load. ((Smalltalk at: #ConfigurationOfSqueakDBX) project version: '1.3') load. That will load and initialize all what it is needed in the image side. > but the system launch a error when I try create and open the > connection to DB. You need the opendbx and sqlite libraries. Everything is explained here: http://www.squeakdbx.org/Compiling%20and%20installing%20OpenDBX or here http://www.squeakdbx.org/Compiling%20for%20different%20backends > Looking in SqueakSource appears too a SQLite project ( > SQLite3-Core and SQLite3-Tests ) but I get the same error... I understand > the problem is for FFI... but I donÂ´t understand what is the cause... > > Is needed something more for run FFI? > As far as I can see in ConfigurationOfFFI you have to do: (Smalltalk at: #ExternalType) initialize. (Smalltalk at: #ExternalStructure) compileAllFields. Smalltalk recreateSpecialObjectsArray > > Thanks for the help. > -- > View this message in context: > http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

Re: [Pharo-project] [OT] NO-SLQ vs RDBMS Re: FluidDB API for Pharo

by GermÃ¡n Arduino

I did some experiments with Cassandra (being that Thrift already produce valid Smalltalk code) and my pov is that nosql are born to solve the scalability problem in terms of horizontal growing, sacrificing some time in consistency. They are named "eventually" consistent, because the delays Randal commented. To some sort of applications, as sort of Facebook or Twitter, are a good option. My 0,02. 2010/9/26 Randal L. Schwartz <merlyn(a)stonehenge.com>: >>>>>> "Mariano" == Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > > Mariano> Hi. Can someone with experience in "No-SQL" databases explain me the > Mariano> differences/advantages over a RDBMS and doing something like: > > Mariano> create table database (key varchar() , value varchar() ) > > I've given a talk a few times about "forget the ORM". Â The slides are up > on http://www.slideshare.net/RandalSchwartz/forget-the-orm > > The key thing that separates a lot of these newer databases is that you > can't have all three of consistency, availability, and performance at > once... you have to sacrifice something. Â Traditional SQL databases > favored consistency over everything, but who cares if your blog page > says "read the 6 comments on this item" for a couple of seconds when > there are really 7 because one just got added. > > The new databases give options for higher availability or performance at > the cost of consistency. Â Some, like Riak (interviewed at > http://twit.tv/floss129) actually let you select on each request how > consistent you want the results, thus controlling how fast you get the > response. Â Thus, for the front page of a blog, you can say "give me a > result that any 1 of the 3 replicas has", but when you finally drill > into the comments, you say "give me a result that all 3 replicas agree > on". Â Of course, these are all *eventually* consistent on the order of > tens or hundreds of milliseconds, but by allowing "almost correct" > results, things are a lot zippier. Â (It also works that way on > write... you can say "come back when any 1 replica says it has it" or > "come back only when all 3 replicas confirm write".) > > So, it's not so much that you get schemaless key/value store (although > that's a frequent feature)... it's that these aren't traditional > databases in a lot of ways. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 4, 2010

Re: [Pharo-project] Newbie question: Connection to SQLite DB

by nullPointer

Well, I first install Sqlite project; I add ConfigurationOfSQLite3 to image. Later: (ConfigurationOfSQLite3 project version: '1.1') load. That seems load Sqlite3 classes and dependences too, FFI included. But if I try execute one example of FFI I get an error. For example: Win32Window win32Draw Now IÂ´m using Windows7 but fails me too Mac Snow Leopard OS... IÂ´m very lost on that subject... Regards -- View this message in context: http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 4, 2010

Re: [Pharo-project] do we need handleDisabledKey:

by Guillermo Polito

So as a first approach, we should use the ParagraphEditor #handleDisabledKey: behavior. Should we? Cheers, Guille On Mon, Oct 4, 2010 at 7:29 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Well, the short answer is "yes" if we want the (previously requested long > ago) features of being able to copy text, browse classes etc. from > selections in disabled text. > > Regards, Gary > > ----- Original Message ----- From: "Gary Chambers" < > gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, October 04, 2010 11:17 AM > Subject: Re: [Pharo-project] do we need handleDisabledKey: > > > > Catching up on emails after being away... will check once software update > completes... > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" < > stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, September 24, 2010 7:01 PM > Subject: [Pharo-project] do we need handleDisabledKey: > > > hi gary >> >> do we need handleDisabledKey: because this is not defined on the new >> editorHierarchy? >> >> http://code.google.com/p/pharo/issues/detail?id=3003 >> >> Stef >> _______________________________________________ >> 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 >

Oct. 4, 2010

Re: [Pharo-project] Newbie question: Connection to SQLite DB

by Levente Uzonyi

On Mon, 4 Oct 2010, nullPointer wrote: > IÂ´m cannot connect a sample SQLite DB. IÂ´m sure need some steps but I donÂ´t know exactly. Really I have alway problems when I try execute some external to Smalltalk image. Exists a document with global information of that? I did install SQueakDBX (with problems for #and:and:and: deprecated method of boolean), but the system launch a error when I try create and open the connection to DB. Looking in SqueakSource appears too a SQLite project ( SQLite3-Core and SQLite3-Tests ) but I get the same error... I understand the problem is for FFI... but I donÂ´t understand what is the cause... Is needed something more for run FFI? You have to install the FFI package. Levente Thanks for the help. -- View this message in context: http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

[Pharo-project] Newbie question: Connection to SQLite DB

by nullPointer

IÂ´m cannot connect a sample SQLite DB. IÂ´m sure need some steps but I donÂ´t know exactly. Really I have alway problems when I try execute some external to Smalltalk image. Exists a document with global information of that? I did install SQueakDBX (with problems for #and:and:and: deprecated method of boolean), but the system launch a error when I try create and open the connection to DB. Looking in SqueakSource appears too a SQLite project ( SQLite3-Core and SQLite3-Tests ) but I get the same error... I understand the problem is for FFI... but I donÂ´t understand what is the cause... Is needed something more for run FFI? Thanks for the help. -- View this message in context: http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 4, 2010

Re: [Pharo-project] Problem with popup lists (Senders of, implementors of etc.)

by Henrik Johansen

This is the same issue as the previously missing method, expect a lot more to pop up. Trouble is Monticello doesn't mark packages dirty correctly when dealing with extension category changes, so the recent Pharo-Kernel lead to alot of method removals rather than movings. http://code.google.com/p/pharo/issues/detail?id=3060 details some of the issues with Monticello, in addition all the recategorization changes should be looked over and fixed in one sweep where removals was the outcome instead of recategorization. Cheers, Henry On Oct 4, 2010, at 12:56 47PM, Gary Chambers wrote: > Hi. > > Since the update to 12168 I am getting an MNU... > Tracked down to > > showMenuOf: selectorCollection withFirstItem: firstItem ifChosenDo: choiceBlock withCaption: aCaption > "Show a sorted menu of the given selectors, preceded by firstItem, and all abbreviated to 40 characters. Use aCaption as the menu title, if it is not nil. Evaluate choiceBlock if a message is chosen." > > | index menuLabels sortedList | > sortedList := selectorCollection asSortedCollection. > menuLabels := Array streamContents: > [:strm | strm nextPutAll: (firstItem contractTo: 40). > sortedList do: [:sel | strm nextPutAll: (sel contractTo: 40)]]. > index := UIManager default chooseFrom: (menuLabels substrings) lines: #(1). > index = 1 ifTrue: [choiceBlock value: firstItem]. > index > 1 ifTrue: [choiceBlock value: (sortedList at: index - 1)] > > The following revision seems to work ok... > > > showMenuOf: selectorCollection withFirstItem: firstItem ifChosenDo: choiceBlock withCaption: aCaption > "Show a sorted menu of the given selectors, preceded by firstItem, and all abbreviated to 40 characters. Use aCaption as the menu title, if it is not nil. Evaluate choiceBlock if a message is chosen." > > | index menuLabels sortedList | > sortedList := selectorCollection asSortedCollection. > menuLabels := Array streamContents: > [:strm | strm nextPut: (firstItem contractTo: 40). > sortedList do: [:sel | strm nextPut: (sel contractTo: 40)]]. > index := UIManager default chooseFrom: menuLabels lines: #(1). > index = 1 ifTrue: [choiceBlock value: firstItem]. > index > 1 ifTrue: [choiceBlock value: (sortedList at: index - 1)] > > Regards, Gary > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

Re: [Pharo-project] Pointer types

by Igor Stasenko

On 4 October 2010 06:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > You mentioned something that might be useful, depending on where it lives. Â Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess. Â Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to<g>) expressing them as void pointers to allow me to pass byte arrays into them. > > Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call? Â If not FFI, how does NB handle it? > In NB, there is a type system, which implements C<->Smalltalk coercions. The responsibility of type coercions taken by a subclasses of NBExternalType, so NB callout code generator actually knows nothing about types and how to coerce them. To create own custom type, you need to subclass from NBExternalType and override methods which responsible for coercions. There you can define any kind of operations , what needs to be done in order to push value on stack, or convert it to some smalltalk object. Then, in your DoubleArray class, simply implement a message on a class side: asNBExternalType: gen ^ MyDoubleArrayExternalType new And then, in FFI callouts you can use a class name directly: DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) etc. Or, if you want make double* type to use it as a DoubleArray, then you can add an alias: MyClass>>externalTypeAlias: aTypeName aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. ^ nil Then, any method which contains an FFI callout in MyClass, will use that alias. So, you can write callout as: double* foo (double *arr, double ** arrPtrPtr) but it will be understood as: DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) About handling pointers.. well for smalltalk there is no pointers, just objects. So, in NB NBExternalType keeps two things: - a value type - a pointer arity So, for example, when you specifying type, like: char *** a value type will be char and pointer arity will be 3. It is up to NBExternalType subclass how to push values whose pointer arity > 0. By default, if pointerArity > 0, then it is treated as a pointer, which can be either: - nil, ByteArray, or NBExternalAddress > Bill > > > > _______________________________________________ > 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.

Oct. 4, 2010

Re: [Pharo-project] [OT] NO-SLQ vs RDBMS Re: FluidDB API for Pharo

by Philippe Marschall

On 26.09.2010 23:46, Randal L. Schwartz wrote: >>>>>> "Mariano" == Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > > Mariano> Hi. Can someone with experience in "No-SQL" databases explain me the > Mariano> differences/advantages over a RDBMS and doing something like: > > Mariano> create table database (key varchar() , value varchar() ) > > I've given a talk a few times about "forget the ORM". The slides are up > on http://www.slideshare.net/RandalSchwartz/forget-the-orm > > The key thing that separates a lot of these newer databases is that you > can't have all three of consistency, availability, and performance at > once... Uhm, the P in CAP does not stand for performance. For more information see [1] [1] http://www.xtranormal.com/watch/6995033/ Cheers Philippe

Oct. 4, 2010

[Pharo-project] Problem with popup lists (Senders of, implementors of etc.)

by Gary Chambers

Hi. Since the update to 12168 I am getting an MNU... Tracked down to showMenuOf: selectorCollection withFirstItem: firstItem ifChosenDo: choiceBlock withCaption: aCaption "Show a sorted menu of the given selectors, preceded by firstItem, and all abbreviated to 40 characters. Use aCaption as the menu title, if it is not nil. Evaluate choiceBlock if a message is chosen." | index menuLabels sortedList | sortedList := selectorCollection asSortedCollection. menuLabels := Array streamContents: [:strm | strm nextPutAll: (firstItem contractTo: 40). sortedList do: [:sel | strm nextPutAll: (sel contractTo: 40)]]. index := UIManager default chooseFrom: (menuLabels substrings) lines: #(1). index = 1 ifTrue: [choiceBlock value: firstItem]. index > 1 ifTrue: [choiceBlock value: (sortedList at: index - 1)] The following revision seems to work ok... showMenuOf: selectorCollection withFirstItem: firstItem ifChosenDo: choiceBlock withCaption: aCaption "Show a sorted menu of the given selectors, preceded by firstItem, and all abbreviated to 40 characters. Use aCaption as the menu title, if it is not nil. Evaluate choiceBlock if a message is chosen." | index menuLabels sortedList | sortedList := selectorCollection asSortedCollection. menuLabels := Array streamContents: [:strm | strm nextPut: (firstItem contractTo: 40). sortedList do: [:sel | strm nextPut: (sel contractTo: 40)]]. index := UIManager default chooseFrom: menuLabels lines: #(1). index = 1 ifTrue: [choiceBlock value: firstItem]. index > 1 ifTrue: [choiceBlock value: (sortedList at: index - 1)] Regards, Gary

Oct. 4, 2010

Re: [Pharo-project] do we need handleDisabledKey:

by Gary Chambers

Well, the short answer is "yes" if we want the (previously requested long ago) features of being able to copy text, browse classes etc. from selections in disabled text. Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, October 04, 2010 11:17 AM Subject: Re: [Pharo-project] do we need handleDisabledKey: Catching up on emails after being away... will check once software update completes... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, September 24, 2010 7:01 PM Subject: [Pharo-project] do we need handleDisabledKey: > hi gary > > do we need handleDisabledKey: because this is not defined on the new > editorHierarchy? > > http://code.google.com/p/pharo/issues/detail?id=3003 > > Stef > _______________________________________________ > 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

Oct. 4, 2010

Re: [Pharo-project] Polymorph shell minimize

by Gary Chambers

Not seen a porblem like that myself Bill. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, September 27, 2010 5:50 PM Subject: [Pharo-project] Polymorph shell minimize > Gary, > > Have you encountered problems after minimizing a standard window? IIRC, I > had one get stuck in that state and was in an "ok, don't do that again" > mood and (I think) forgot to mention it. It is not a stretch to think > that I might have done something wrong in building the view. > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010