Re: [Pharo-users] PetitParser: Parse X as long as it's not Y

[Sean P. DeNigris]

vonbecmann wrote
> did you try with negate?

That is the standard trick with PP, but the problem here is that I'm trying
to say, not just "anything which is not Y", but "any string of these
characters as long is it doesn't also match Y"



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/PetitParser-Parse-X-as-long-as-it-s-not-Y-tp4958895p4958912.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

[Herby Vojčík]

Herby Vojčík wrote:

Guillermo Polito wrote:

AFAIR, PharoDatabaseAccessor was meant to work with SqueakDBX/DBXTalk
driver. No other driver should use it. At the time Garage did not even
exist.

So I'd say that you should not use PharoDatabaseAccessor with another
driver than the one it was originally mean to? I do not know exactly
your setup, I was not following this thread.

Really I cannot tell much more. This was really long time ago.


Great to know!

I am not using it consciously, though. System somehow selects it and
uses it in the background (I just do MyDescriptorSystem sessionForLogin:
myLoginObject; and before that I set GarageGlorpDrive to be the default).

This seems to be the actual fix (make Glorp with Garage not use
PharoDatabaseAccessor).


Actually, probably not. It is more in, it should be fixed to work with 
Garage. It has lots of functionality there... :-(




Herby



On Sun, Aug 6, 2017 at 12:20 AM, Herby Vojčík > wrote:

Esteban A. Maringolo wrote:

Herby,

I regularly use `session login`, but I don't use SQLite in
Pharo, but I
do in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo


It's hard. The problem is

PharoDatabaseAccessor >> encoding
^self connection queryEncoding

which overrides parent, which is atm:

encoding
"The connection is specific to the dialect; some dialects will need
to override this method."

^connection encoding

The former was added at GuillermoPolito.73 back in 2011 (and the
latter was the same back then). It probably fixed something, but I
don't see any implementors of queryEncoding atm (definitely not in
Garage). From the diff it is clear lots of databases and drivers
have gone. Now, why was it change for Pharo (and does it need to be
changed in 2017)?

Ccing Guillermo Polito.

Herby

P.S.: I wonder how it is that no one actually had problem with this?
This predictably fails on `session login` on pharo, unless
queryEncoding is somehow magically present without seeing it in
source code for other platforms?


2017-08-05 15:52 GMT-03:00 Herby Vojčík 
>>:

Alistair Grant wrote:

Hi Herby,

On 5 August 2017 at 18:09, Herby
Vojčík
>> wrote:

Hello!

First of all, what is preferred way to (first time)
login
into database? I
had the impression that `aDatabaseAccessor login`
is sorta
low-level, and
one should do `session login` (after all, it is
session you
get to work
with, not an accessor).

But with Garage SQLite, `session login`, when
accessor is
not logged, always
fails with "MessageNotUnderstood:
GASqlite3Driver>>queryEncoding".

Should one not use `session login` at all, then (when
accessor is logged, it
just does nothing, if it isn't, it connects the
accessor,
but tries to do
some additional work which always fails)?

Herby


From memory this is caused by differences between
VisualWorks
and Pharo.

Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html

>


Doesn't look like solved to me. Anyway, at least I know it
is known
for year and no-one seemed to see it as a bug.

I think it is one (you cannot just send queryEncoding where
no class
implements it and be fine, imo).

So what is the state of `session login`? Is it meant to be
used, or
everyone just took a step down to low-level and uses `accessor
login` instead? :-(


Cheers,
Alistair


Thanks, Herby






--



Guille Polito


Research Engineer

French National Center for Scientific Research - _http://www.cnrs.fr_



*Web:* _http://guillep.github.io_

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Best Practices for Bundling Documentation

[Evan Donahue]

Hello,

The projects are a logic programming and machine learning system
respectively, so they probably warrant more involved tutorial-style
documentation. I will take a look at the Pillar docs, but just to think
ahead a bit, assuming I write up some docs in Pillar, what would be the best
way to distribute those? Can they be packaged with the code or would the
docs be outside the image? If outside, where do people tend to host them?

Thanks,
Evan



--
View this message in context: 
http://forum.world.st/Best-Practices-for-Bundling-Documentation-tp4958788p4958910.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

[Herby Vojčík]

Guillermo Polito wrote:

AFAIR, PharoDatabaseAccessor was meant to work with SqueakDBX/DBXTalk
driver. No other driver should use it. At the time Garage did not even
exist.

So I'd say that you should not use PharoDatabaseAccessor with another
driver than the one it was originally mean to? I do not know exactly
your setup, I was not following this thread.

Really I cannot tell much more. This was really long time ago.


Great to know!

I am not using it consciously, though. System somehow selects it and 
uses it in the background (I just do MyDescriptorSystem sessionForLogin: 
myLoginObject; and before that I set GarageGlorpDrive to be the default).


This seems to be the actual fix (make Glorp with Garage not use 
PharoDatabaseAccessor).


Herby



On Sun, Aug 6, 2017 at 12:20 AM, Herby Vojčík > wrote:

Esteban A. Maringolo wrote:

Herby,

I regularly use `session login`, but I don't use SQLite in
Pharo, but I
do in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo


It's hard. The problem is

PharoDatabaseAccessor >> encoding
  ^self connection queryEncoding

which overrides parent, which is atm:

encoding
"The connection is specific to the dialect;  some dialects will need
to override this method."

 ^connection encoding

The former was added at GuillermoPolito.73 back in 2011 (and the
latter was the same back then). It probably fixed something, but I
don't see any implementors of queryEncoding atm (definitely not in
Garage). From the diff it is clear lots of databases and drivers
have gone. Now, why was it change for Pharo (and does it need to be
changed in 2017)?

Ccing Guillermo Polito.

Herby

P.S.: I wonder how it is that no one actually had problem with this?
This predictably fails on `session login` on pharo, unless
queryEncoding is somehow magically present without seeing it in
source code for other platforms?


2017-08-05 15:52 GMT-03:00 Herby Vojčík 
>>:

 Alistair Grant wrote:

 Hi Herby,

 On 5 August 2017 at 18:09, Herby
Vojčík
>>  wrote:

 Hello!

 First of all, what is preferred way to (first time)
login
 into database? I
 had the impression that `aDatabaseAccessor login`
is sorta
 low-level, and
 one should do `session login` (after all, it is
session you
 get to work
 with, not an accessor).

 But with Garage SQLite, `session login`, when
accessor is
 not logged, always
 fails with "MessageNotUnderstood:
 GASqlite3Driver>>queryEncoding".

 Should one not use `session login` at all, then (when
 accessor is logged, it
 just does nothing, if it isn't, it connects the
accessor,
 but tries to do
 some additional work which always fails)?

 Herby


   From memory this is caused by differences between
VisualWorks
 and Pharo.

 Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html

>


 Doesn't look like solved to me. Anyway, at least I know it
is known
 for year and no-one seemed to see it as a bug.

 I think it is one (you cannot just send queryEncoding where
no class
 implements it and be fine, imo).

 So what is the state of `session login`? Is it meant to be
used, or
 everyone just took a step down to low-level and uses `accessor
 login` instead? :-(


 Cheers,
 Alistair


 Thanks, Herby






--



Guille Polito


Research Engineer

French National Center for Scientific Research - _http://www.cnrs.fr_



*Web:* _http://guillep.github.io_

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

[Herby Vojčík]

Esteban A. Maringolo wrote:

Which version of Pharo, Glorp and SQLite are you using?


As for SQLite dll, I don't know (does it change the fact if 
queryEncoding method is present?).


Pharo is 6.1, Glorp, Garage etc. are #stable loaded from Pharo60 catalog 
(see attachment).


Herby




Esteban A. Maringolo


2017-08-05 19:20 GMT-03:00 Herby Vojčík:

Esteban A. Maringolo wrote:

Herby,

I regularly use `session login`, but I don't use SQLite in Pharo, but I
do in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo


It's hard. The problem is

PharoDatabaseAccessor>>  encoding
  ^self connection queryEncoding

which overrides parent, which is atm:

encoding
 "The connection is specific to the dialect;  some dialects will need
to override this method."

 ^connection encoding

The former was added at GuillermoPolito.73 back in 2011 (and the latter was
the same back then). It probably fixed something, but I don't see any
implementors of queryEncoding atm (definitely not in Garage). From the diff
it is clear lots of databases and drivers have gone. Now, why was it change
for Pharo (and does it need to be changed in 2017)?

Ccing Guillermo Polito.

Herby

P.S.: I wonder how it is that no one actually had problem with this? This
predictably fails on `session login` on pharo, unless queryEncoding is
somehow magically present without seeing it in source code for other
platforms?


2017-08-05 15:52 GMT-03:00 Herby Vojčík>:

 Alistair Grant wrote:

 Hi Herby,

 On 5 August 2017 at 18:09, Herby Vojčík>   wrote:

 Hello!

 First of all, what is preferred way to (first time) login
 into database? I
 had the impression that `aDatabaseAccessor login` is sorta
 low-level, and
 one should do `session login` (after all, it is session you
 get to work
 with, not an accessor).

 But with Garage SQLite, `session login`, when accessor is
 not logged, always
 fails with "MessageNotUnderstood:
 GASqlite3Driver>>queryEncoding".

 Should one not use `session login` at all, then (when
 accessor is logged, it
 just does nothing, if it isn't, it connects the accessor,
 but tries to do
 some additional work which always fails)?

 Herby


   From memory this is caused by differences between VisualWorks
 and Pharo.

 Anyway, it is discussed and resolved in:

 http://forum.world.st/Glorp-SQLite3-issue-td4899792.html
 


 Doesn't look like solved to me. Anyway, at least I know it is known
 for year and no-one seemed to see it as a bug.

 I think it is one (you cannot just send queryEncoding where no class
 implements it and be fine, imo).

 So what is the state of `session login`? Is it meant to be used, or
 everyone just took a step down to low-level and uses `accessor
 login` instead? :-(


 Cheers,
 Alistair


 Thanks, Herby

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

[Esteban A. Maringolo]

Which version of Pharo, Glorp and SQLite are you using?


Esteban A. Maringolo


2017-08-05 19:20 GMT-03:00 Herby Vojčík :
> Esteban A. Maringolo wrote:
>>
>> Herby,
>>
>> I regularly use `session login`, but I don't use SQLite in Pharo, but I
>> do in VisualWorks and it works just fine.
>> Maybe if there is a bug we should fix it. Even with a no-op method.
>>
>> Regards!
>>
>> Esteban A. Maringolo
>
>
> It's hard. The problem is
>
> PharoDatabaseAccessor >> encoding
>  ^self connection queryEncoding
>
> which overrides parent, which is atm:
>
> encoding
> "The connection is specific to the dialect;  some dialects will need
> to override this method."
>
> ^connection encoding
>
> The former was added at GuillermoPolito.73 back in 2011 (and the latter was
> the same back then). It probably fixed something, but I don't see any
> implementors of queryEncoding atm (definitely not in Garage). From the diff
> it is clear lots of databases and drivers have gone. Now, why was it change
> for Pharo (and does it need to be changed in 2017)?
>
> Ccing Guillermo Polito.
>
> Herby
>
> P.S.: I wonder how it is that no one actually had problem with this? This
> predictably fails on `session login` on pharo, unless queryEncoding is
> somehow magically present without seeing it in source code for other
> platforms?
>
>>
>> 2017-08-05 15:52 GMT-03:00 Herby Vojčík > >:
>>
>> Alistair Grant wrote:
>>
>> Hi Herby,
>>
>> On 5 August 2017 at 18:09, Herby Vojčík> >  wrote:
>>
>> Hello!
>>
>> First of all, what is preferred way to (first time) login
>> into database? I
>> had the impression that `aDatabaseAccessor login` is sorta
>> low-level, and
>> one should do `session login` (after all, it is session you
>> get to work
>> with, not an accessor).
>>
>> But with Garage SQLite, `session login`, when accessor is
>> not logged, always
>> fails with "MessageNotUnderstood:
>> GASqlite3Driver>>queryEncoding".
>>
>> Should one not use `session login` at all, then (when
>> accessor is logged, it
>> just does nothing, if it isn't, it connects the accessor,
>> but tries to do
>> some additional work which always fails)?
>>
>> Herby
>>
>>
>>   From memory this is caused by differences between VisualWorks
>> and Pharo.
>>
>> Anyway, it is discussed and resolved in:
>>
>> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html
>> 
>>
>>
>> Doesn't look like solved to me. Anyway, at least I know it is known
>> for year and no-one seemed to see it as a bug.
>>
>> I think it is one (you cannot just send queryEncoding where no class
>> implements it and be fine, imo).
>>
>> So what is the state of `session login`? Is it meant to be used, or
>> everyone just took a step down to low-level and uses `accessor
>> login` instead? :-(
>>
>>
>> Cheers,
>> Alistair
>>
>>
>> Thanks, Herby
>>
>>
>
>

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

[Guillermo Polito]

AFAIR, PharoDatabaseAccessor was meant to work with SqueakDBX/DBXTalk
driver. No other driver should use it. At the time Garage did not even
exist.

So I'd say that you should not use PharoDatabaseAccessor with another
driver than the one it was originally mean to? I do not know exactly your
setup, I was not following this thread.

Really I cannot tell much more. This was really long time ago.

On Sun, Aug 6, 2017 at 12:20 AM, Herby Vojčík  wrote:

> Esteban A. Maringolo wrote:
>
>> Herby,
>>
>> I regularly use `session login`, but I don't use SQLite in Pharo, but I
>> do in VisualWorks and it works just fine.
>> Maybe if there is a bug we should fix it. Even with a no-op method.
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>
> It's hard. The problem is
>
> PharoDatabaseAccessor >> encoding
>  ^self connection queryEncoding
>
> which overrides parent, which is atm:
>
> encoding
> "The connection is specific to the dialect;  some dialects will
> need to override this method."
>
> ^connection encoding
>
> The former was added at GuillermoPolito.73 back in 2011 (and the latter
> was the same back then). It probably fixed something, but I don't see any
> implementors of queryEncoding atm (definitely not in Garage). From the diff
> it is clear lots of databases and drivers have gone. Now, why was it change
> for Pharo (and does it need to be changed in 2017)?
>
> Ccing Guillermo Polito.
>
> Herby
>
> P.S.: I wonder how it is that no one actually had problem with this? This
> predictably fails on `session login` on pharo, unless queryEncoding is
> somehow magically present without seeing it in source code for other
> platforms?
>
>
>> 2017-08-05 15:52 GMT-03:00 Herby Vojčík > >:
>>
>> Alistair Grant wrote:
>>
>> Hi Herby,
>>
>> On 5 August 2017 at 18:09, Herby Vojčík> >  wrote:
>>
>> Hello!
>>
>> First of all, what is preferred way to (first time) login
>> into database? I
>> had the impression that `aDatabaseAccessor login` is sorta
>> low-level, and
>> one should do `session login` (after all, it is session you
>> get to work
>> with, not an accessor).
>>
>> But with Garage SQLite, `session login`, when accessor is
>> not logged, always
>> fails with "MessageNotUnderstood:
>> GASqlite3Driver>>queryEncoding".
>>
>> Should one not use `session login` at all, then (when
>> accessor is logged, it
>> just does nothing, if it isn't, it connects the accessor,
>> but tries to do
>> some additional work which always fails)?
>>
>> Herby
>>
>>
>>   From memory this is caused by differences between VisualWorks
>> and Pharo.
>>
>> Anyway, it is discussed and resolved in:
>>
>> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html
>> 
>>
>>
>> Doesn't look like solved to me. Anyway, at least I know it is known
>> for year and no-one seemed to see it as a bug.
>>
>> I think it is one (you cannot just send queryEncoding where no class
>> implements it and be fine, imo).
>>
>> So what is the state of `session login`? Is it meant to be used, or
>> everyone just took a step down to low-level and uses `accessor
>> login` instead? :-(
>>
>>
>> Cheers,
>> Alistair
>>
>>
>> Thanks, Herby
>>
>>
>>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Lazy-initialization patterns

[Esteban A. Maringolo]

2017-08-05 19:21 GMT-03:00 Peter Uhnak :

> If I want to initialize the value in a separate method (typically for testing 
> or reuse), then I prefer to avoid state mutation there and instead I return 
> the result.
>
> MyClass>>#property
> ^ property ifNil: [ property := self createNewProperty ]
>
> MyClass>>createNewProperty
> "I won't touch property instance variable here, just create a new 
> value and return it"
> ^ self bar collect: [ :e | e drink ]
>
>
> > an initializationMethod returning the value instead of the receiver is a 
> > code smell to me.
>
> For this reason I tend to name such methods createNewX, initializeX says to 
> me "only mutate state and return self"

I like this approach very much, it makes the accessor code concise and
separates the implementation of the property creation.

Thank you!

Esteban A. Maringolo

Re: [Pharo-users] Lazy-initialization patterns

[Esteban A. Maringolo]

I know the compiler is smart enough in most cases, and even if it isn't, an
extra send or two won't hurt me in the kind of computation I do.

But it's the style what "worried" me the most.

Let's use the first then :)


Esteban A. Maringolo

2017-08-05 19:18 GMT-03:00 Paul DeBruicker :

> Seems like either way would have unmeasurable performance impact for your
> application vs the other and you should go for whats most
> legible/comprehensible.
>
>
> On that metric I prefer the first but #yolo
>
>
>
>
>
>
>
> Esteban A. Maringolo wrote
> > Hi there,
> >
> > I have a question about lazy initialization accessor methods that always
> > keep me thinking in terms of performance and style.
> >
> > For years I did something like:
> >
> > MyClass>>#property
> >   property isNil ifTrue: [ self initializeProperty ]. "It could be ifNil:
> > as well"
> >   ^property
> >
> > MyClass>>#initializeProperty
> >   "Returns the receiver, not the property."
> >property := self foo collect: [:e | ... ].
> >
> >
> > But this made me think that maybe I'm performing extra operations, so I
> > started doing something like:
> >
> > MyClass>>#property
> >   ^property ifNil: [ self initializeProperty ]
> >
> > MyClass>>#initializeProperty
> >   ^property := self foo collect: [:e | ... ]
> >
> > The initialize method is often created by an "Extract Method" refactoring
> > I
> > do in the accesor, where I do the initial implementation.
> >
> >
> > The messages makes me think that the second implementation is "faster",
> > but
> > an initializationMethod returning the value instead of the receiver is a
> > code smell to me.
> >
> > I early initialize everything I know will be be used right away, but for
> > cases it doesn't make sense.
> >
> >
> > What do you think/prefer? Why?
> >
> > Maybe we could use the reified variables (slots) to implement the lazy
> > initialization themselves :)
> >
> >
> > Best regards!
> >
> > Esteban A. Maringolo
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/Lazy-
> initialization-patterns-tp4958897p4958901.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Re: [Pharo-users] Lazy-initialization patterns

[Peter Uhnak]

Personally I prever to avoid long lazy initializations, so I have it nice and 
tidy in a single method.

MyClass>>#property
^ property ifNil: [ property := self bar collect: #food ]

If I want to initialize the value in a separate method (typically for testing 
or reuse), then I prefer to avoid state mutation there and instead I return the 
result.

MyClass>>#property
^ property ifNil: [ property := self createNewProperty ]

MyClass>>createNewProperty
"I won't touch property instance variable here, just create a new value 
and return it"
^ self bar collect: [ :e | e drink ]


> an initializationMethod returning the value instead of the receiver is a code 
> smell to me.

For this reason I tend to name such methods createNewX, initializeX says to me 
"only mutate state and return self"

Peter

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

[Herby Vojčík]

Esteban A. Maringolo wrote:

Herby,

I regularly use `session login`, but I don't use SQLite in Pharo, but I
do in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo


It's hard. The problem is

PharoDatabaseAccessor >> encoding
 ^self connection queryEncoding

which overrides parent, which is atm:

encoding
	"The connection is specific to the dialect;  some dialects will need to 
override this method."


^connection encoding

The former was added at GuillermoPolito.73 back in 2011 (and the latter 
was the same back then). It probably fixed something, but I don't see 
any implementors of queryEncoding atm (definitely not in Garage). From 
the diff it is clear lots of databases and drivers have gone. Now, why 
was it change for Pharo (and does it need to be changed in 2017)?


Ccing Guillermo Polito.

Herby

P.S.: I wonder how it is that no one actually had problem with this? 
This predictably fails on `session login` on pharo, unless queryEncoding 
is somehow magically present without seeing it in source code for other 
platforms?




2017-08-05 15:52 GMT-03:00 Herby Vojčík >:

Alistair Grant wrote:

Hi Herby,

On 5 August 2017 at 18:09, Herby Vojčík>  wrote:

Hello!

First of all, what is preferred way to (first time) login
into database? I
had the impression that `aDatabaseAccessor login` is sorta
low-level, and
one should do `session login` (after all, it is session you
get to work
with, not an accessor).

But with Garage SQLite, `session login`, when accessor is
not logged, always
fails with "MessageNotUnderstood:
GASqlite3Driver>>queryEncoding".

Should one not use `session login` at all, then (when
accessor is logged, it
just does nothing, if it isn't, it connects the accessor,
but tries to do
some additional work which always fails)?

Herby


  From memory this is caused by differences between VisualWorks
and Pharo.

Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html



Doesn't look like solved to me. Anyway, at least I know it is known
for year and no-one seemed to see it as a bug.

I think it is one (you cannot just send queryEncoding where no class
implements it and be fine, imo).

So what is the state of `session login`? Is it meant to be used, or
everyone just took a step down to low-level and uses `accessor
login` instead? :-(


Cheers,
Alistair


Thanks, Herby

Re: [Pharo-users] Lazy-initialization patterns

[Paul DeBruicker]

Seems like either way would have unmeasurable performance impact for your
application vs the other and you should go for whats most
legible/comprehensible.


On that metric I prefer the first but #yolo  







Esteban A. Maringolo wrote
> Hi there,
> 
> I have a question about lazy initialization accessor methods that always
> keep me thinking in terms of performance and style.
> 
> For years I did something like:
> 
> MyClass>>#property
>   property isNil ifTrue: [ self initializeProperty ]. "It could be ifNil:
> as well"
>   ^property
> 
> MyClass>>#initializeProperty
>   "Returns the receiver, not the property."
>property := self foo collect: [:e | ... ].
> 
> 
> But this made me think that maybe I'm performing extra operations, so I
> started doing something like:
> 
> MyClass>>#property
>   ^property ifNil: [ self initializeProperty ]
> 
> MyClass>>#initializeProperty
>   ^property := self foo collect: [:e | ... ]
> 
> The initialize method is often created by an "Extract Method" refactoring
> I
> do in the accesor, where I do the initial implementation.
> 
> 
> The messages makes me think that the second implementation is "faster",
> but
> an initializationMethod returning the value instead of the receiver is a
> code smell to me.
> 
> I early initialize everything I know will be be used right away, but for
> cases it doesn't make sense.
> 
> 
> What do you think/prefer? Why?
> 
> Maybe we could use the reified variables (slots) to implement the lazy
> initialization themselves :)
> 
> 
> Best regards!
> 
> Esteban A. Maringolo





--
View this message in context: 
http://forum.world.st/Lazy-initialization-patterns-tp4958897p4958901.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] PetitParser: Parse X as long as it's not Y

[Bernardo Ezequiel Contreras]

did you try with negate?

comment
^ ($" asParser , $" asParser negate star , $" asParser) flatten



On Sat, Aug 5, 2017 at 5:26 PM, Sean P. DeNigris 
wrote:

> How do I tell Petit Parser to parse a string of certain allowable
> characters
> as long as the final result isn't a particular string? E.g. consume an
> identifier as long as it's not 'Baz' or 'Bar'
>
> Thanks
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/
> PetitParser-Parse-X-as-long-as-it-s-not-Y-tp4958895.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>


-- 
Bernardo E.C.

Sent from a cheap desktop computer in South America.

[Pharo-users] Lazy-initialization patterns

[Esteban A. Maringolo]

Hi there,

I have a question about lazy initialization accessor methods that always
keep me thinking in terms of performance and style.

For years I did something like:

MyClass>>#property
  property isNil ifTrue: [ self initializeProperty ]. "It could be ifNil:
as well"
  ^property

MyClass>>#initializeProperty
  "Returns the receiver, not the property."
   property := self foo collect: [:e | ... ].


But this made me think that maybe I'm performing extra operations, so I
started doing something like:

MyClass>>#property
  ^property ifNil: [ self initializeProperty ]

MyClass>>#initializeProperty
  ^property := self foo collect: [:e | ... ]

The initialize method is often created by an "Extract Method" refactoring I
do in the accesor, where I do the initial implementation.


The messages makes me think that the second implementation is "faster", but
an initializationMethod returning the value instead of the receiver is a
code smell to me.

I early initialize everything I know will be be used right away, but for
cases it doesn't make sense.


What do you think/prefer? Why?

Maybe we could use the reified variables (slots) to implement the lazy
initialization themselves :)


Best regards!

Esteban A. Maringolo

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

[Esteban A. Maringolo]

Herby,

I regularly use `session login`, but I don't use SQLite in Pharo, but I do
in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo

2017-08-05 15:52 GMT-03:00 Herby Vojčík :

> Alistair Grant wrote:
>
>> Hi Herby,
>>
>> On 5 August 2017 at 18:09, Herby Vojčík  wrote:
>>
>>> Hello!
>>>
>>> First of all, what is preferred way to (first time) login into database?
>>> I
>>> had the impression that `aDatabaseAccessor login` is sorta low-level, and
>>> one should do `session login` (after all, it is session you get to work
>>> with, not an accessor).
>>>
>>> But with Garage SQLite, `session login`, when accessor is not logged,
>>> always
>>> fails with "MessageNotUnderstood: GASqlite3Driver>>queryEncoding".
>>>
>>> Should one not use `session login` at all, then (when accessor is
>>> logged, it
>>> just does nothing, if it isn't, it connects the accessor, but tries to do
>>> some additional work which always fails)?
>>>
>>> Herby
>>>
>>
>>  From memory this is caused by differences between VisualWorks and Pharo.
>>
>> Anyway, it is discussed and resolved in:
>>
>> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html
>>
>
> Doesn't look like solved to me. Anyway, at least I know it is known for
> year and no-one seemed to see it as a bug.
>
> I think it is one (you cannot just send queryEncoding where no class
> implements it and be fine, imo).
>
> So what is the state of `session login`? Is it meant to be used, or
> everyone just took a step down to low-level and uses `accessor login`
> instead? :-(
>
>
>> Cheers,
>> Alistair
>>
>>
> Thanks, Herby
>
>

[Pharo-users] PetitParser: Parse X as long as it's not Y

[Sean P. DeNigris]

How do I tell Petit Parser to parse a string of certain allowable characters
as long as the final result isn't a particular string? E.g. consume an
identifier as long as it's not 'Baz' or 'Bar'

Thanks



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/PetitParser-Parse-X-as-long-as-it-s-not-Y-tp4958895.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

[Herby Vojčík]

Alistair Grant wrote:

Hi Herby,

On 5 August 2017 at 18:09, Herby Vojčík  wrote:

Hello!

First of all, what is preferred way to (first time) login into database? I
had the impression that `aDatabaseAccessor login` is sorta low-level, and
one should do `session login` (after all, it is session you get to work
with, not an accessor).

But with Garage SQLite, `session login`, when accessor is not logged, always
fails with "MessageNotUnderstood: GASqlite3Driver>>queryEncoding".

Should one not use `session login` at all, then (when accessor is logged, it
just does nothing, if it isn't, it connects the accessor, but tries to do
some additional work which always fails)?

Herby


 From memory this is caused by differences between VisualWorks and Pharo.

Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html


Doesn't look like solved to me. Anyway, at least I know it is known for 
year and no-one seemed to see it as a bug.


I think it is one (you cannot just send queryEncoding where no class 
implements it and be fine, imo).


So what is the state of `session login`? Is it meant to be used, or 
everyone just took a step down to low-level and uses `accessor login` 
instead? :-(




Cheers,
Alistair



Thanks, Herby

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

[Alistair Grant]

Hi Herby,

On 5 August 2017 at 18:09, Herby Vojčík  wrote:
> Hello!
>
> First of all, what is preferred way to (first time) login into database? I
> had the impression that `aDatabaseAccessor login` is sorta low-level, and
> one should do `session login` (after all, it is session you get to work
> with, not an accessor).
>
> But with Garage SQLite, `session login`, when accessor is not logged, always
> fails with "MessageNotUnderstood: GASqlite3Driver>>queryEncoding".
>
> Should one not use `session login` at all, then (when accessor is logged, it
> just does nothing, if it isn't, it connects the accessor, but tries to do
> some additional work which always fails)?
>
> Herby

>From memory this is caused by differences between VisualWorks and Pharo.

Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html

Cheers,
Alistair

Re: [Pharo-users] problem with FLMaterializer

[Johannes Brauer]

In the EnterprisePharo Book there is a chapter "Fuel Format Migration". There 
the format migration form Fuel version 1.7 to 1.9 is shown. I ask me if there 
is a similar possibility for the migration between Fuel in Pharo 4 and 6.

Johannes
Am 05.08.2017 um 15:08 schrieb Cyril Ferlicot 
>:


On sam. 5 août 2017 at 13:10, Johannes Brauer 
> wrote:
Peter

Your suggestion is correct. I correct the expression to

(FLMaterializer materializeFromFileNamed: aFileRefence fullName)

Now I get another exception.
KeyNotFound: key #'ositive8SmallIntegerClusterJ 4Ü 1‚ ð+ –( %? "< 9 ª 6P M ¾0 d 
*ÒD ''x ! Œ 8' not found in SystemDictionary
I think this is a compatibility problem between different Fuel versions.

Hi,

If you use Fuel to serialize objects with Pharo 4, then you can only 
materialize them with a Fuel from Pharo 4. Other versions of Fuel will not be 
able to read them.


Johannes

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Re: [Pharo-users] about a pillar based output format for Epicea

[Stephane Ducasse]

This is question of time and energy.
I should restart to work and make it smaller and nicer.
I want ecstatic too.

On Wed, Aug 2, 2017 at 10:21 PM, Tim Mackinnon  wrote:
> Out of curiosity (as Pillar - well actually Ecstatic, was on my next hitlist
> to research), but is it so different from something like JavaScripts
> Metalsmith.io ? I found metalsmith’s publishing pipeline and plugin system
> quite intuitive and easy to use but I just didn’t like nodejs so much (and
> the crappy webpack/brunch auto reloading systems).
>
> It struck me that what they were doing was quite trivial in Smalltalk and I
> assumed Pillar (and Ecstatic) were similar in concept. However when I had a
> peak it did look quite complicated and made me think that porting Metalsmith
> might be easier and in interesting personal project.
>
> Anyway, might be worth a look if you want architectural inspiration.
>
> Tim
>
> Sent from my iPhone
>
>
> On 2 Aug 2017, at 18:19, Stephane Ducasse  wrote:
>
> I'm because Pillar is central to all my writings around Pharo (books,
> slides,...).
> We also want to use it for a lecture on open-source development.
>
> Pillar got too complex and we should simplify its architecture.
>
> I'm working on a new version of Cocoon but this tedious and I got
> stuck in managing
> initialisation of fields (from text to objects). now I will continue
> to work but task switching is killing me.
> Guillermo is helping me from time to time and damien helps me with the
> makefile/latex.
>
> I will first finish all the slides for my lectures at Prague first.
>
> Now we made
> - sure that we can run archetype without being forced to passed by the
> command-line.
> - and many changes and cleanup.
> Now we should work on
>
> - Make sure that we identify for real bugs showing up in the three
> different archetypes (slides, books...).
> - Avoid to convert to JSON files to apply mustache.
>
> - Rethink the architecture.
> - Like removing the dependency on magritte from the core.
> - Avoid a lot of strange behavior related to metadata handling.
>
> Stef
>
>
> On Wed, Aug 2, 2017 at 6:15 PM, Alexandre Bergel
>  wrote:
>
> Pillar is becoming central in the way I produce documents.
> Is there anyone working on improving Pillar?
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Aug 2, 2017, at 11:55 AM, Stephane Ducasse 
> wrote:
>
> Hi martin
>
> I would like to wlak over epicea objects and save the changed methods
> to be able to write booklets faster.
> What advices can you give me?
> Create a special visitor?
>
> Stef
>
>
>
>

Re: [Pharo-users] Best Practices for Bundling Documentation

[Stephane Ducasse]

Hi Evan

Depending on the size of the documentation.
- if you have a kind of tutorial I would go (and I can help) for a
pillar booklet or a chapter.
- else class comments are simply cool with examples


stef

On Sat, Aug 5, 2017 at 2:19 AM, Evan Donahue  wrote:
> Hello,
>
> I'm working on cleaning up a couple of projects for release, and I was
> wondering what the best practices were for including appropriate
> documentation with projects. Should I just drop a text blob in a prominent
> class comment? Is there a tool for structuring documentation? Is
> documentation typically kept separate from the code? Seems natural to
> include it so you never have to leave the image, but I'm not sure what most
> people do.
>
> Thanks,
> Evan

[Pharo-users] Glorp: `session login` fails for Garage SQLite

[Herby Vojčík]

Hello!

First of all, what is preferred way to (first time) login into database? 
I had the impression that `aDatabaseAccessor login` is sorta low-level, 
and one should do `session login` (after all, it is session you get to 
work with, not an accessor).


But with Garage SQLite, `session login`, when accessor is not logged, 
always fails with "MessageNotUnderstood: GASqlite3Driver>>queryEncoding".


Should one not use `session login` at all, then (when accessor is 
logged, it just does nothing, if it isn't, it connects the accessor, but 
tries to do some additional work which always fails)?


Herby

Re: [Pharo-users] problem with FLMaterializer

[Cyril Ferlicot]

On sam. 5 août 2017 at 13:10, Johannes Brauer 
wrote:

> Peter
>
> Your suggestion is correct. I correct the expression to
>
> (FLMaterializer materializeFromFileNamed: aFileRefence *fullName*)
>
> Now I get another exception.
> KeyNotFound: key #'ositive8SmallIntegerClusterJ 4Ü 1‚ ð+ –( %? "< 9 ª 6P M
> ¾0 d *ÒD ''x ! Œ 8' not found in SystemDictionary
> I think this is a compatibility problem between different Fuel versions.
>

Hi,

If you use Fuel to serialize objects with Pharo 4, then you can only
materialize them with a Fuel from Pharo 4. Other versions of Fuel will not
be able to read them.


> Johannes
>
> --
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Re: [Pharo-users] problem with FLMaterializer

[Johannes Brauer]

Peter

Your suggestion is correct. I correct the expression to

(FLMaterializer materializeFromFileNamed: aFileRefence fullName)

Now I get another exception.
KeyNotFound: key #'ositive8SmallIntegerClusterJ4Ü1‚ð+–( 
%?"<9ª6PM¾0d*ÒD ''x!Œ8' not found in SystemDictionary
I think this is a compatibility problem between different Fuel versions.

Johannes

Am 05.08.2017 um 11:13 schrieb PBKResearch 
>:

Johannes

Just a suggestion: FLMaterializer class >>materializeFromFileNamed: requires as 
argument aFilename, not aFileRefence. Presumably this means the name as a 
string. This makes sense, because #convertToWithConverter: is the name of a 
method understood by strings. If your invocation of the materializer includes 
asFileReference, try again without that.

Hope this helps

Peter Kenny

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Johannes Brauer
Sent: 04 August 2017 23:56
To: Any question about pharo is welcome 
>
Subject: [Pharo-users] problem with FLMaterializer

Hi everyone,

 trying to migrate a Seaside application from Pharo4 to Pharo6 I get a problem 
with FLMaterializer.

An expression like

(FLMaterializer materializeFromFileNamed: aFileRefence)

results in
MessageNotUnderstood: FileReference>>convertToWithConverter:
The same file can be materialized in Pharo4  without problems.

Johannes

Re: [Pharo-users] problem with FLMaterializer

[PBKResearch]

Johannes

 

Just a suggestion: FLMaterializer class >>materializeFromFileNamed: requires
as argument aFilename, not aFileRefence. Presumably this means the name as a
string. This makes sense, because #convertToWithConverter: is the name of a
method understood by strings. If your invocation of the materializer
includes asFileReference, try again without that.

 

Hope this helps

 

Peter Kenny

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
Johannes Brauer
Sent: 04 August 2017 23:56
To: Any question about pharo is welcome 
Subject: [Pharo-users] problem with FLMaterializer

 

Hi everyone,

 trying to migrate a Seaside application from Pharo4 to Pharo6 I get a
problem with FLMaterializer.

 

An expression like

 

(FLMaterializer materializeFromFileNamed: aFileRefence)

 

results in


MessageNotUnderstood: FileReference>>convertToWithConverter:


The same file can be materialized in Pharo4  without problems.

 

Johannes