Re: [Pharo-users] How to depend on another Github repo from the baseline ?

[kilon alios]

Thank you both, I changed my code accordingly to load SmaCC as the example
of Thierry.

Re: [Pharo-users] Starting with Pharo Issue Tracker

[stepharo]

Thanks!
We are busy with deadlines these weeks :)

Stef

Le 25/3/15 00:14, Ben Coman a écrit :



On Wed, Mar 25, 2015 at 2:33 AM, Peter Uhnák > wrote:


http://pharo.org/contribute-propose-fix


Thats great Jigyasa.  Always good to have more contributors. Now for 
those of us who have been doing it a while, it is not always obvious 
where there are gaps to get new people started off.  So please ask 
plenty of question if you get stuck.


Is your question that you don't have a particular bug to work on and 
would like a suggestion?
* Check that reported bugs include have suitable steps-to-reproduce. 
If not, then ask the submitter for more details and report on the 
issue if you are able to reproduce it.


* Start by reviewing other people fixes.  Sometimes these are in deep 
places that are daunting at first, but I learnt an immense amount 
doing this when I started, and continue to do so.  Do the first step 
of merging in a SLICE from the Pharo4Inbox (soon to be Pharo5Inbox) 
but don't complete it - keep it as a reference.  Open the Inbox again 
and do the merge for real.  Then throw a few halts into the modified 
methods and try to reproduce the bug.  You learn Pharo best by 
watching it run, not just looking at code.


* In an image without the bug fix, put halts in the same methods, then 
single step both images in sync until you can observe differences - 
and that is where you learn the most.


Tip: At the link above, where it says... "Take the latest stable or 
latest development system, ideally using the latest virtual machine 
(check the _downloads_)" - I'd suggest using PharoLauncher 
(http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher 
) which makes 
it very easy to grab the latest build.


cheers -ben

Re: [Pharo-users] Collection with memory?

[stepharo]

Stef,

Like Denis said, there is no #next: in Xtreams, AFIACT.


Yes but this is the same
we should get  read and read: and not get and read:
This is my point.


There are

XTReadStream>>#get
   "Read an object from self.
If there aren't any elements left in the stream, the Incomplete exception is 
raised."

and

XTReadStream>>#read: anInteger
   "Read anInteger's worth of elements from self and return them in a 
collection.
If full anInteger number of elements cannot be read from the source, the 
Incomplete exception is raised."

Like I said, these selector names were chosen to prevent confusion, on purpose. 
I think that is good. I also think that a lot of though went into the design.

I personally think that
get and read: are bad and irregular.

XTReadStream>>#read
  "Read an object from self.
   If there aren't any elements left in the stream, the Incomplete exception is 
raised."

XTReadStream>>#read: anInteger
  "Read anInteger's worth of elements from self and return them in a collection.
   If full anInteger number of elements cannot be read from the source, the 
Incomplete exception is raised."


funny how the comments are good. No need to change them. This is a sign.


#++ could be aliased to #seekForward: and #-- to #seekBackward: I guess. I also 
do not really like the look of them.


I will not aliased them. Just deprecate them :)
I do not want to have to always scratch my head to understand the code
seekForward and seekBackward is much much nicer.


BTW, I think that the compatibility layer/wrapper is not good (I would be very 
surprised if it could hide all the semantic differences). What is the point to 
switch to a new stream API if you hide it ?

Incremental migration.


Also, the current stream API is 'too wide', there are too many methods, too 
much is expected from streams. To change that, the users must be changed.


Yes we will do that.


Sven


On 23 Mar 2015, at 22:06, stepharo  wrote:



Yes but with
r next.
r next

The choice for different selector names was intentional, by design. To avoid 
confusion, because #next and #get are not 100% identical (semantically). This 
is an important point.

No I asked martin personally. This is the real reason.  There were also 
experimenting to offer an API closer to other language.
So that we have
r get.
r next: 4

IIRC, one difference between #get and #next is that

  get cannot return nil and will throw an Incomplete exception when EOF
  next can return nil and might throws an Exception

Changing the meaning of an existing selector will cause many problems and 
discussions. People will think they do not have to change anything and they 
will be wrong.

Indeed now this is still not a nice API.
So what would be a nice name for get

I do not get it. I'm probably too tired

get so it is named get and not next.
get cannot return nil and will throw an Incomplete exception when EOF
but
next: that could be confused with next
can return nil and might throws an Exception (because it should follow 
next) :)
No stupid stef.
next: is from xtreams so it should follow get
get cannot return nil and will throw an Incomplete exception when EOF
A this is probably clear.

So could we be consistent

nextItem
nextItems:
putItem:


Now since in anyways people will have to revisit they wrapping of next calls
which should probably wraped into and Exception.
I do not see the problem. It is because there is a wrapper that would turn an 
Xstream stream into a old API (then again I do not understand
because since the wrapper is another class it can have a next method that 
delegates to the correct wrapped xstream which may have or not the same api.
So what is the point?

I mean once xtream will replace the old one it will be for about 10 years so
I'm sorry but we should get the api right (and yes I know that ++ -= are 
correct smalltalk still they SUCK).

Stef

Re: [Pharo-users] Boardician (board game framework)

[stepharo]

We should help laura and do a code review.

Laura I do not know if you change it in the latext version but I would 
not subclass from Matrix but use composition instead.



Le 24/3/15 15:41, Laura Risani a écrit :

Hi all,

A time ago i posted two board games on the list and Stéphane said that 
he would like to extract from these and other ones he has gathered a 
framework for doing board games. So i developed a little one called 
'Boardician' and implemented four little example games through it.


DOCUMENTATION
http://boardician.blogspot.com.ar/2015/03/boardician.html

DOWNLOAD 
You can install configuration BgBoardician from Configuration Browser 
on 3.0 and 4.0 . This will download packages of framework 
(BgBoardician) and example games (BgBoxPush, BgEatBullet, BgDropPiece, 
BgEatElongating)


To run example games send

EDirector new play.
BPDirector new play.
DPDirector new play.
GDirector new play.


FEEDBACK 
If you like (i would really like you to) to send any feedback comments 
on design / names / implementation / functionalities to add / 
questions you can post a comment on the blog / mail me.


Next i'll be adding tests and uploading development history to 
project's repo.


Best,
Laura

Re: [Pharo-users] Boardician (board game framework)

[stepharo]

Hi laura

I would do a massive rename :)

EDirector new play.
does not tell me anything

BPDirector new play.
DPDirector new play.
GDirector new play.

neither :)

Stef

Le 24/3/15 15:41, Laura Risani a écrit :

Hi all,

A time ago i posted two board games on the list and Stéphane said that 
he would like to extract from these and other ones he has gathered a 
framework for doing board games. So i developed a little one called 
'Boardician' and implemented four little example games through it.


DOCUMENTATION
http://boardician.blogspot.com.ar/2015/03/boardician.html

DOWNLOAD 
You can install configuration BgBoardician from Configuration Browser 
on 3.0 and 4.0 . This will download packages of framework 
(BgBoardician) and example games (BgBoxPush, BgEatBullet, BgDropPiece, 
BgEatElongating)


To run example games send

EDirector new play.
BPDirector new play.
DPDirector new play.
GDirector new play.


FEEDBACK 
If you like (i would really like you to) to send any feedback comments 
on design / names / implementation / functionalities to add / 
questions you can post a comment on the blog / mail me.


Next i'll be adding tests and uploading development history to 
project's repo.


Best,
Laura

Re: [Pharo-users] new link to query all projects in smalltalkhub

[Stephan Eggermont]

On 24/03/15 17:36, Merwan Ouddane wrote:

Thanks for the instructions,

I'll do it as soon as I can :)

There is an issue that i'd like to report too, I have a team with a
non-ascii character, and i can't remove team members nor delete the
entire team, I'll try to fix it too.


That sounds like a good issue to experiment with on your own
installation first :)
Thanks for picking this up.

Stephan

Re: [Pharo-users] Collection with memory?

[Sven Van Caekenberghe]

OK, I get your point now, #read and #read: are a better combination than #get 
and #read:

About #++ and friends, yes I think they are so uncommon that they do not 
warrant a special selector, what is the point ?

> On 25 Mar 2015, at 09:12, stepharo  wrote:
> 
>> Stef,
>> 
>> Like Denis said, there is no #next: in Xtreams, AFIACT.
> 
> Yes but this is the same
> we should get  read and read: and not get and read:
> This is my point.
>> 
>> There are
>> 
>> XTReadStream>>#get
>>   "Read an object from self.
>>If there aren't any elements left in the stream, the Incomplete exception 
>> is raised."
>> 
>> and
>> 
>> XTReadStream>>#read: anInteger
>>   "Read anInteger's worth of elements from self and return them in a 
>> collection.
>>If full anInteger number of elements cannot be read from the source, the 
>> Incomplete exception is raised."
>> 
>> Like I said, these selector names were chosen to prevent confusion, on 
>> purpose. I think that is good. I also think that a lot of though went into 
>> the design.
> I personally think that
> get and read: are bad and irregular.
> 
> XTReadStream>>#read
>  "Read an object from self.
>   If there aren't any elements left in the stream, the Incomplete exception 
> is raised."
> 
> XTReadStream>>#read: anInteger
>  "Read anInteger's worth of elements from self and return them in a 
> collection.
>   If full anInteger number of elements cannot be read from the source, the 
> Incomplete exception is raised."
> 
> 
> funny how the comments are good. No need to change them. This is a sign.

Re: [Pharo-users] Git overriding repo load from different source

[Jan B.]

Hello

I was able to get by those warnings automatically by adding onLock: [ :ex |
ex disallow ]; in addition to onConflict

Metacello new
baseline: '...'
repository: 'gitfiletree:///.../repository'
onConflict: [ :ex | ex allow ];
onLock: [ :ex | ex disallow ];
load

I'm not sure whether it couldn't cause any problems, but it seems to be
working.

Jan


Peter Uhnák wrote
>> If so then the trick is to use the Metacello `lock` ... Do the following
>> BEFORE loading the project that depends upon you sample project:
>>
> Combined with onConflict: mentioned by Thierry this works like a charm,
> thanks a lot. :)
> 
> 
>> (a Warning is dumped to the transcript) ...
>>
> I got a warning prompt which I had confirm ("proceed") couple of times,
> but
> that's just a detail.
> 
> Thanks a lot!
> 
> Peter





--
View this message in context: 
http://forum.world.st/Git-overriding-repo-load-from-different-source-tp4813857p4815009.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Starting with Pharo Issue Tracker

[Jigyasa Grover]

Exactly my question.
Thanks for the help :)



--
View this message in context: 
http://forum.world.st/Starting-with-Pharo-Issue-Tracker-tp4814883p4815016.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] USB in Pharo?

[Udo Schneider]

Just had a quick start with TalkFFI ... and after getting 32bit libs on 
Mac OS X it finally worked.


However running TalkFFI results in a wallback because (I assume) a type 
can't be infered. Is there any way to debug TalkFFI to get the C name of 
the offending type/function? All I'm seeing are their addresses :-(


CU,

Udo


On 24/03/15 17:33, kilon alios wrote:

If the library is big you can use TalkFFI (you will find it in
smalltalkhub) that automates the wrapping with nativeboost.

On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider
mailto:udo.schnei...@homeaddress.de>> wrote:

I guess not :-)

I'll try to wrap libUSB then.

I assume the future-proof way to use "a" FFI framework is to use the
NB notation? Do I remember correctly that the NB notation is
supposed to remain the same although the backend will change to
something more like traditional FFI?
So using NB notation w/o relying on the code generation is safe,
correct?

CU,

Udo



On 23.03.2015 16:15, Udo Schneider wrote:

All,

does anybody have some code or plugin to access USB ports with
Pharo?
Maybe something using libUSB or OpenUSB?

Thanks,

Udo

Re: [Pharo-users] USB in Pharo?

[Udo Schneider]

I found the offending code. The original code is something like:

struct libusb_bos_dev_capability_descriptor *dev_capability
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
[] /* valid C99 code */
#else
[0] /* non-standard, but usually working code */
#endif
;

This doesn't work with clang/TalkFFI. I assume based on the #defines it 
uses the C99 notation which doesn't work. "Hardcoding" it to the 
non-standard notation does work. E.g.:


struct libusb_bos_dev_capability_descriptor *dev_capability
//#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
//  [] /* valid C99 code */
//#else
[0] /* non-standard, but usually working code */
//#endif
;

It seems that this was the only showstopper as TalkFFI just generated a 
binding for the whole library w/o any problem.


I'll start experimenting now ...

CU,

Udo


On 24/03/15 17:33, kilon alios wrote:

If the library is big you can use TalkFFI (you will find it in
smalltalkhub) that automates the wrapping with nativeboost.

On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider
mailto:udo.schnei...@homeaddress.de>> wrote:

I guess not :-)

I'll try to wrap libUSB then.

I assume the future-proof way to use "a" FFI framework is to use the
NB notation? Do I remember correctly that the NB notation is
supposed to remain the same although the backend will change to
something more like traditional FFI?
So using NB notation w/o relying on the code generation is safe,
correct?

CU,

Udo



On 23.03.2015 16:15, Udo Schneider wrote:

All,

does anybody have some code or plugin to access USB ports with
Pharo?
Maybe something using libUSB or OpenUSB?

Thanks,

Udo

Re: [Pharo-users] USB in Pharo?

[Luc Fabresse]

Hi Udo,

Thanks to report your experience on TalkFFI.
Can you also post a small step by step tutorial of what you did to generate
the NB bindings ?

Thanks,

#Luc

2015-03-25 11:37 GMT+01:00 Udo Schneider :

> I found the offending code. The original code is something like:
>
> struct libusb_bos_dev_capability_descriptor *dev_capability
> #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
> [] /* valid C99 code */
> #else
> [0] /* non-standard, but usually working code */
> #endif
> ;
>
> This doesn't work with clang/TalkFFI. I assume based on the #defines it
> uses the C99 notation which doesn't work. "Hardcoding" it to the
> non-standard notation does work. E.g.:
>
> struct libusb_bos_dev_capability_descriptor *dev_capability
> //#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
> //  [] /* valid C99 code */
> //#else
> [0] /* non-standard, but usually working code */
> //#endif
> ;
>
> It seems that this was the only showstopper as TalkFFI just generated a
> binding for the whole library w/o any problem.
>
> I'll start experimenting now ...
>
> CU,
>
> Udo
>
>
> On 24/03/15 17:33, kilon alios wrote:
>
>> If the library is big you can use TalkFFI (you will find it in
>> smalltalkhub) that automates the wrapping with nativeboost.
>>
>> On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider
>> > > wrote:
>>
>> I guess not :-)
>>
>> I'll try to wrap libUSB then.
>>
>> I assume the future-proof way to use "a" FFI framework is to use the
>> NB notation? Do I remember correctly that the NB notation is
>> supposed to remain the same although the backend will change to
>> something more like traditional FFI?
>> So using NB notation w/o relying on the code generation is safe,
>> correct?
>>
>> CU,
>>
>> Udo
>>
>>
>>
>> On 23.03.2015 16:15, Udo Schneider wrote:
>>
>> All,
>>
>> does anybody have some code or plugin to access USB ports with
>> Pharo?
>> Maybe something using libUSB or OpenUSB?
>>
>> Thanks,
>>
>> Udo
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>

Re: [Pharo-users] USB in Pharo?

[Udo Schneider]

Hi Luc,

Yepp will do. Time to write a blog entry again :-)

CU,

Udo


On 25/03/15 11:42, Luc Fabresse wrote:

Hi Udo,

Thanks to report your experience on TalkFFI.
Can you also post a small step by step tutorial of what you did to
generate the NB bindings ?

Thanks,

#Luc

2015-03-25 11:37 GMT+01:00 Udo Schneider
mailto:udo.schnei...@homeaddress.de>>:

I found the offending code. The original code is something like:

 struct libusb_bos_dev_capability___descriptor *dev_capability
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
 [] /* valid C99 code */
#else
 [0] /* non-standard, but usually working code */
#endif
;

This doesn't work with clang/TalkFFI. I assume based on the #defines
it uses the C99 notation which doesn't work. "Hardcoding" it to the
non-standard notation does work. E.g.:

 struct libusb_bos_dev_capability___descriptor *dev_capability
//#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
//  [] /* valid C99 code */
//#else
 [0] /* non-standard, but usually working code */
//#endif
;

It seems that this was the only showstopper as TalkFFI just
generated a binding for the whole library w/o any problem.

I'll start experimenting now ...

CU,

Udo


On 24/03/15 17:33, kilon alios wrote:

If the library is big you can use TalkFFI (you will find it in
smalltalkhub) that automates the wrapping with nativeboost.

On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider
mailto:udo.schnei...@homeaddress.de>
>>
wrote:

 I guess not :-)

 I'll try to wrap libUSB then.

 I assume the future-proof way to use "a" FFI framework is
to use the
 NB notation? Do I remember correctly that the NB notation is
 supposed to remain the same although the backend will change to
 something more like traditional FFI?
 So using NB notation w/o relying on the code generation is
safe,
 correct?

 CU,

 Udo



 On 23.03.2015 16:15, Udo Schneider wrote:

 All,

 does anybody have some code or plugin to access USB
ports with
 Pharo?
 Maybe something using libUSB or OpenUSB?

 Thanks,

 Udo

Re: [Pharo-users] USB in Pharo?

[Luc Fabresse]

Nice, thanks a lot!

Luc

2015-03-25 11:47 GMT+01:00 Udo Schneider :

> Hi Luc,
>
> Yepp will do. Time to write a blog entry again :-)
>
> CU,
>
> Udo
>
>
> On 25/03/15 11:42, Luc Fabresse wrote:
>
>> Hi Udo,
>>
>> Thanks to report your experience on TalkFFI.
>> Can you also post a small step by step tutorial of what you did to
>> generate the NB bindings ?
>>
>> Thanks,
>>
>> #Luc
>>
>> 2015-03-25 11:37 GMT+01:00 Udo Schneider
>> > >:
>>
>> I found the offending code. The original code is something like:
>>
>>  struct libusb_bos_dev_capability___descriptor
>> *dev_capability
>> #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
>>  [] /* valid C99 code */
>> #else
>>  [0] /* non-standard, but usually working code */
>> #endif
>> ;
>>
>> This doesn't work with clang/TalkFFI. I assume based on the #defines
>> it uses the C99 notation which doesn't work. "Hardcoding" it to the
>> non-standard notation does work. E.g.:
>>
>>  struct libusb_bos_dev_capability___descriptor
>> *dev_capability
>> //#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
>> //  [] /* valid C99 code */
>> //#else
>>  [0] /* non-standard, but usually working code */
>> //#endif
>> ;
>>
>> It seems that this was the only showstopper as TalkFFI just
>> generated a binding for the whole library w/o any problem.
>>
>> I'll start experimenting now ...
>>
>> CU,
>>
>> Udo
>>
>>
>> On 24/03/15 17:33, kilon alios wrote:
>>
>> If the library is big you can use TalkFFI (you will find it in
>> smalltalkhub) that automates the wrapping with nativeboost.
>>
>> On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider
>> > 
>> > >>
>> wrote:
>>
>>  I guess not :-)
>>
>>  I'll try to wrap libUSB then.
>>
>>  I assume the future-proof way to use "a" FFI framework is
>> to use the
>>  NB notation? Do I remember correctly that the NB notation is
>>  supposed to remain the same although the backend will change
>> to
>>  something more like traditional FFI?
>>  So using NB notation w/o relying on the code generation is
>> safe,
>>  correct?
>>
>>  CU,
>>
>>  Udo
>>
>>
>>
>>  On 23.03.2015 16:15, Udo Schneider wrote:
>>
>>  All,
>>
>>  does anybody have some code or plugin to access USB
>> ports with
>>  Pharo?
>>  Maybe something using libUSB or OpenUSB?
>>
>>  Thanks,
>>
>>  Udo
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>

Re: [Pharo-users] USB in Pharo?

[kilon alios]

I have not used TalkFFI I only know that it exists. Very glad it works for
you and I am also very interested on a blog post how you got it working and
how you solved your problems. I am sure it will come handy one day :)

On Wed, Mar 25, 2015 at 12:37 PM, Udo Schneider <
udo.schnei...@homeaddress.de> wrote:

> I found the offending code. The original code is something like:
>
> struct libusb_bos_dev_capability_descriptor *dev_capability
> #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
> [] /* valid C99 code */
> #else
> [0] /* non-standard, but usually working code */
> #endif
> ;
>
> This doesn't work with clang/TalkFFI. I assume based on the #defines it
> uses the C99 notation which doesn't work. "Hardcoding" it to the
> non-standard notation does work. E.g.:
>
> struct libusb_bos_dev_capability_descriptor *dev_capability
> //#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
> //  [] /* valid C99 code */
> //#else
> [0] /* non-standard, but usually working code */
> //#endif
> ;
>
> It seems that this was the only showstopper as TalkFFI just generated a
> binding for the whole library w/o any problem.
>
> I'll start experimenting now ...
>
> CU,
>
> Udo
>
>
> On 24/03/15 17:33, kilon alios wrote:
>
>> If the library is big you can use TalkFFI (you will find it in
>> smalltalkhub) that automates the wrapping with nativeboost.
>>
>> On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider
>> > > wrote:
>>
>> I guess not :-)
>>
>> I'll try to wrap libUSB then.
>>
>> I assume the future-proof way to use "a" FFI framework is to use the
>> NB notation? Do I remember correctly that the NB notation is
>> supposed to remain the same although the backend will change to
>> something more like traditional FFI?
>> So using NB notation w/o relying on the code generation is safe,
>> correct?
>>
>> CU,
>>
>> Udo
>>
>>
>>
>> On 23.03.2015 16:15, Udo Schneider wrote:
>>
>> All,
>>
>> does anybody have some code or plugin to access USB ports with
>> Pharo?
>> Maybe something using libUSB or OpenUSB?
>>
>> Thanks,
>>
>> Udo
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>

Re: [Pharo-users] Settings browser

[Hilaire]

Le 24/03/2015 21:22, Alain Plantec via Pharo-users a écrit :
> Have a look at the setting chapter (The Setting Framework) 


Hi Alain,

Thanks Alain.
I was already studying the chapter yesterday, but it appears there is an
unexpected complication,
In a singleton DrGeoStylePreference class I define the methods as follow:

drgeoStylesOn: aBuilder

(aBuilder group: #drgeoStyle)
label: 'Style';
with: [
(aBuilder group: #point)
label: 'Point' translated;
with: [
(aBuilder setting: #pointColor)
label: 'Colour' translated].
../..

then

pointColor
  ^ current "respond the singleton, widget build up set later"

settingInputWidgetForNode: aSettingDeclaration
^ (aSettingDeclaration name, 'Widget') asSymbol value: self.

pointColorWidget
^ (UITheme builder
newMorphDropListFor: self
list: #colorMorphCollection
getSelected: #pointColorIndex
setSelected: #pointColorIndex:
help: 'Set the colour.' translated) minWidth: DrGIcons
menuExtent x + 35
../..

and so on.

The complication comes from the SettingDeclaration>>inputWidget where
the widget model is set to the SettingDeclaration, and it breaks:

inputWidget
"return the default widget for the input a the setting"
../..
inputWidget
ifNotNil: [(inputWidget respondsTo: #model:)
ifTrue: [inputWidget model: self]].
../..

If I remove the #model: call, it is ok.

Did I miss something?

Thanks

Hilaire

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

Re: [Pharo-users] Settings browser

[Alain Plantec via Pharo-users]

--- Begin Message ---

> Le 25 mars 2015 à 12:19, Hilaire  a écrit :
> 
> settingInputWidgetForNode: aSettingDeclaration
>^ (aSettingDeclaration name, 'Widget') asSymbol value: self.
> 

strange that you send the #value: message to a Symbol here.
Alain--- End Message ---

Re: [Pharo-users] Boardician (board game framework)

[Ben Coman]

One pattern is that the main application class be fully named, leaving the
mnemonic prefix for the support classes.
cheers -ben

On Wed, Mar 25, 2015 at 4:14 PM, stepharo  wrote:

>  Hi laura
>
> I would do a massive rename :)
>
> EDirector new play.
> does not tell me anything
>
> BPDirector new play.
> DPDirector new play.
> GDirector new play.
>
> neither :)
>
> Stef
>
> Le 24/3/15 15:41, Laura Risani a écrit :
>
> Hi all,
>
>  A time ago i posted two board games on the list and Stéphane said that
> he would like to extract from these and other ones he has gathered a
> framework for doing board games. So i developed a little one called
> 'Boardician' and implemented four little example games through it.
>
>  DOCUMENTATION
> http://boardician.blogspot.com.ar/2015/03/boardician.html
>
>  DOWNLOAD 
> You can install configuration BgBoardician from Configuration Browser on
> 3.0 and 4.0 . This will download packages of framework (BgBoardician) and
> example games (BgBoxPush, BgEatBullet, BgDropPiece, BgEatElongating)
>
> To run example games send
>
> EDirector new play.
> BPDirector new play.
> DPDirector new play.
> GDirector new play.
>
>
> FEEDBACK 
> If you like (i would really like you to) to send any feedback comments on
> design / names / implementation / functionalities to add / questions you
> can post a comment on the blog / mail me.
>
>  Next i'll be adding tests and uploading development history to project's
> repo.
>
>  Best,
>  Laura
>
>
>

[Pharo-users] Packaging for Mac OS

[Hernán Morales Durand]

Guys,

I wish to package my Pharo applications for Mac OS. But I don't have a Mac
and my own finances demonstrates I won't have one anytime soon.

Do you know if there is a (free? :) remote Mac OS service (like a remote
shell) where I can log-in, package my image, and download the resulting
file?

Hernán

Re: [Pharo-users] Packaging for Mac OS

[Esteban Lorenzano]

Nope, but you could download Pharo for mac and just change the image on it (a 
Mac app is just a subdirectory)

Esteban

> On 25 Mar 2015, at 13:38, Hernán Morales Durand  
> wrote:
> 
> Guys,
> 
> I wish to package my Pharo applications for Mac OS. But I don't have a Mac 
> and my own finances demonstrates I won't have one anytime soon.
> 
> Do you know if there is a (free? :) remote Mac OS service (like a remote 
> shell) where I can log-in, package my image, and download the resulting file?
> 
> Hernán
> 

Re: [Pharo-users] Packaging for Mac OS

[Ben Coman]

Possible alternative...
http://www.macbreaker.com/2013/01/iatkos-ml2-mountain-lion-virtualbox.html

cheers -ben

On Wed, Mar 25, 2015 at 8:38 PM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

> Guys,
>
> I wish to package my Pharo applications for Mac OS. But I don't have a Mac
> and my own finances demonstrates I won't have one anytime soon.
>
> Do you know if there is a (free? :) remote Mac OS service (like a remote
> shell) where I can log-in, package my image, and download the resulting
> file?
>
> Hernán
>
>

Re: [Pharo-users] Settings browser

[Hilaire]

Le 25/03/2015 12:39, Alain Plantec via Pharo-users a écrit :
>>
>> settingInputWidgetForNode: aSettingDeclaration
>>^ (aSettingDeclaration name, 'Widget') asSymbol value: self.
>>
>
> strange that you send the #value: message to a Symbol here.
> Alain

It is tricky indeed, but it is the only way I found to by-pass the
limitation for customized widget:
as I understood it, settings browser expects one class (a type) per
dedicated widget. I can latter create a dedicated class for each drop
list morph I need in the settings browser, then remove this strange
by-pass, I am still exploring.
Nevertheless, it does not seem related to the model problem I exposed
previously.

Thanks

Hilaire

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

Re: [Pharo-users] Packaging for Mac OS

[Hernán Morales Durand]

Thanks Ben,
I tried the hackintosh with the VMWare but not on VirtualBox. Let's see how
it goes.

Hernán

2015-03-25 9:52 GMT-03:00 Ben Coman :

> Possible alternative...
> http://www.macbreaker.com/2013/01/iatkos-ml2-mountain-lion-virtualbox.html
>
> cheers -ben
>
> On Wed, Mar 25, 2015 at 8:38 PM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>> Guys,
>>
>> I wish to package my Pharo applications for Mac OS. But I don't have a
>> Mac and my own finances demonstrates I won't have one anytime soon.
>>
>> Do you know if there is a (free? :) remote Mac OS service (like a remote
>> shell) where I can log-in, package my image, and download the resulting
>> file?
>>
>> Hernán
>>
>>
>

Re: [Pharo-users] Code formatting - preserving newlines and comments

[Davide Varvello via Pharo-users]

--- Begin Message ---
Thanks Peter, really useful for readability
Davide



--
View this message in context: 
http://forum.world.st/Code-formatting-preserving-newlines-and-comments-tp4773967p4815079.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

--- End Message ---

Re: [Pharo-users] Boardician (board game framework)

[Laura Risani]

@olivier
I guess that playing to test them should be considered to work.

@kilon
Mail me back if you do develop a game adding from you graphical
capabilities.

@stepharo , Ben
Code review would be nice!

I've tried to chose the most meaningful names, yet i didn't discuss this
with anyone, what would be adequate since communication is interpersonal.
If you show me, telling why, you think another name would communicate
better instead a current one i'll change it. Also i'd like more people to
have an opinion on this.

I agree that games' director names are meaningless, seems that something
like '(BG)DirectorOfGameName' would communicate better and be more
practical since when you type 'BGDirector' code completition will show all
the existing game director subclasses, that is all the games.

@stepharo
I subclass from Matrix BGBoardSpace and DPPieceLayout. These  are
respectively matrix arrangements of places (BGBoardPlace) and squares
(DPSquare) that (potentially) need to understand all Matrix interface in
addition to extending it (for example class side methods for instantiating
particular space cases like level spaces, instance side methods for telling
space properties). I think it's like having to model matrix of numbers that
would need to support all math matrix operations, why not to subclass? why
to rewrite all matrix interface?
Composition takes place at the level of BGBoard and DPPiece (which are
respectively composed by aBGBoardSpace and aDPPieceLayout), so substitution
could occur there if you need a non matrix space (is that to be expected?).
Why do you think composing BGBoardSpace and DPPieceLayout would be better?




On Wed, Mar 25, 2015 at 9:01 AM, Ben Coman  wrote:

> One pattern is that the main application class be fully named, leaving the
> mnemonic prefix for the support classes.
> cheers -ben
>
> On Wed, Mar 25, 2015 at 4:14 PM, stepharo  wrote:
>
>>  Hi laura
>>
>> I would do a massive rename :)
>>
>> EDirector new play.
>> does not tell me anything
>>
>> BPDirector new play.
>> DPDirector new play.
>> GDirector new play.
>>
>> neither :)
>>
>> Stef
>>
>> Le 24/3/15 15:41, Laura Risani a écrit :
>>
>> Hi all,
>>
>>  A time ago i posted two board games on the list and Stéphane said that
>> he would like to extract from these and other ones he has gathered a
>> framework for doing board games. So i developed a little one called
>> 'Boardician' and implemented four little example games through it.
>>
>>  DOCUMENTATION
>> http://boardician.blogspot.com.ar/2015/03/boardician.html
>>
>>  DOWNLOAD 
>> You can install configuration BgBoardician from Configuration Browser on
>> 3.0 and 4.0 . This will download packages of framework (BgBoardician) and
>> example games (BgBoxPush, BgEatBullet, BgDropPiece, BgEatElongating)
>>
>> To run example games send
>>
>> EDirector new play.
>> BPDirector new play.
>> DPDirector new play.
>> GDirector new play.
>>
>>
>> FEEDBACK 
>> If you like (i would really like you to) to send any feedback comments on
>> design / names / implementation / functionalities to add / questions you
>> can post a comment on the blog / mail me.
>>
>>  Next i'll be adding tests and uploading development history to
>> project's repo.
>>
>>  Best,
>>  Laura
>>
>>
>>
>

Re: [Pharo-users] Git overriding repo load from different source

[Dale Henrichs]

On 3/24/15 11:47 PM, Peter Uhnák wrote:
On Sun, Mar 22, 2015 at 11:19 PM, Dale Henrichs 
> wrote:


I keep an eye out for posts with Metacello in the subject line so
I missed this one ...

I'll keep that in mind next time.

If so then the trick is to use the Metacello `lock` ... Do the
following BEFORE loading the project that depends upon you sample
project:

Combined with onConflict: mentioned by Thierry this works like a 
charm, thanks a lot. :)


(a Warning is dumped to the transcript) ...

I got a warning prompt which I had confirm ("proceed") couple of 
times, but that's just a detail.



Peter,

There's an onWarningLog message that will catch the Warning, log it to 
the Transcript and proceeed ... there's also an onWarning: message that 
lets you customize your response ...


Dale

Re: [Pharo-users] Git overriding repo load from different source

[Dale Henrichs]

On 3/25/15 1:35 AM, Jan B. wrote:

Hello

I was able to get by those warnings automatically by adding onLock: [ :ex |
ex disallow ]; in addition to onConflict

Metacello new
baseline: '...'
repository: 'gitfiletree:///.../repository'
onConflict: [ :ex | ex allow ];
onLock: [ :ex | ex disallow ];
load

I'm not sure whether it couldn't cause any problems, but it seems to be
working.



I'd recommend that you not put in the unconditional onConflict: ... at 
one point in time the onConflict: was required to handle locks, but 
currently the default handler for onConflict: will honor locks and the 
default handler for onLock: will dump signal a Warning and then honor 
the lock.


Putting in onLock: as you've done _is_ a good way to bypass the onLock: 
Warnings ... you can use `honor` instead of `disallow` and `break` 
instead of `allow` for the onLock: notification as those messages read a 
bit better ...


The interesting onConflict: notifications occur when an incoming project 
decides to change the version or repository or configuration type 
(BaselineOf or ConfigurationOf) ... so if you care to know when this 
type of thing happens, then you can _leave off the onConflict:_ and 
you'll get a chance to decide if you want to have that change made to 
your system, before it is loaded rather than discover the change after 
it is loaded ... this is basically why I added the onLock: message - so 
that you weren't tempted to add an uncoditional onConflict: block just 
because you were working with locks:)


Dale

[Pharo-users] Monitoring spotter

[Alexandre Bergel]

Hi!

The GT crew recently introduces in Pharo a way to keep track of what people are 
searching in the system. 
This is a highly valuable piece of information that could benefit everybody. 

For example, I would love to know which Roassal classes are looking the most 
often. Or which Roassal examples people are repeatedly searching.

However, this is hard to know currently. The reason is because of anonymity. No 
strings are stored in what is being sent over. To me, this is _highly 
counter-productive_: if you are working with sensitive information (I don’t 
personally), then do not send things over. But enforcing anonymity generate 
frustration. 

So, here is my call:

If you care about letting us improving the tools everybody use, feel free to 
reveal your identity. Simply send the result of the following expression:

GTSpotterEventRecorderSettings uniqueInstance secretUUID hash

For me
=> 195966943

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-users] Boardician (board game framework)

[stepharo]

Le 25/3/15 16:32, Laura Risani a écrit :

@olivier
I guess that playing to test them should be considered to work.

@kilon
Mail me back if you do develop a game adding from you graphical 
capabilities.


@stepharo , Ben
Code review would be nice!

I've tried to chose the most meaningful names, yet i didn't discuss 
this with anyone, what would be adequate since communication is 
interpersonal. If you show me, telling why, you think another name 
would communicate better instead a current one i'll change it. Also 
i'd like more people to have an opinion on this.


I agree that games' director names are meaningless, seems that 
something like '(BG)DirectorOfGameName' would communicate better and 
be more practical since when you type 'BGDirector' code completition 
will show all the existing game director subclasses, that is all the 
games.


@stepharo
I subclass from MatrixBGBoardSpace and DPPieceLayout. These  are 
respectively matrix arrangements of places (BGBoardPlace) and squares 
(DPSquare) that (potentially) need to understand all Matrix interface 
in addition to extending it (for example class side methods for 
instantiating particular space cases like level spaces, instance side 
methods for telling space properties). I think it's like having to 
model matrix of numbers that would need to support all math 
matrix operations, why not to subclass? why to rewrite all 
matrix interface?

Favor subtyping over subclassing.
A subclass Matrix should be a specific Matrix with matrix behavior.

Subclassing is not a really good practice. It is code reuse but this is 
short term.
Imagine that tomorrow we put some eigenvalues in Matrix will this 
eigenValue make sense for your board. I do not think so.


Following the same we removed in Pharo
Dictionary as subclass of Set.
Now dictionary is a subclass of HashedCollection.

We did not because it did not work but because it sucked and let to all 
kind of understanding problems.


Composition takes place at the level of BGBoard and DPPiece (which are 
respectively composed by aBGBoardSpace and aDPPieceLayout), so 
substitution could occur there if you need a non matrix space (is that 
to be expected?).

Why do you think composing BGBoardSpace and DPPieceLayout would be better?




On Wed, Mar 25, 2015 at 9:01 AM, Ben Coman > wrote:


One pattern is that the main application class be fully named,
leaving the mnemonic prefix for the support classes.
cheers -ben

On Wed, Mar 25, 2015 at 4:14 PM, stepharo mailto:steph...@free.fr>> wrote:

Hi laura

I would do a massive rename :)

EDirector new play.
does not tell me anything

BPDirector new play.
DPDirector new play.
GDirector new play.

neither :)

Stef

Le 24/3/15 15:41, Laura Risani a écrit :

Hi all,

A time ago i posted two board games on the list and Stéphane
said that he would like to extract from these and other ones
he has gathered a framework for doing board games. So i
developed a little one called 'Boardician' and implemented
four little example games through it.

DOCUMENTATION
http://boardician.blogspot.com.ar/2015/03/boardician.html

DOWNLOAD 
You can install configuration BgBoardician from Configuration
Browser on 3.0 and 4.0 . This will download packages of
framework (BgBoardician) and example games (BgBoxPush,
BgEatBullet, BgDropPiece, BgEatElongating)

To run example games send

EDirector new play.
BPDirector new play.
DPDirector new play.
GDirector new play.


FEEDBACK 
If you like (i would really like you to) to send any feedback
comments on design / names / implementation / functionalities
to add / questions you can post a comment on the blog / mail me.

Next i'll be adding tests and uploading development history
to project's repo.

Best,
Laura

Re: [Pharo-users] Using Google service discovery API's with Pharo Smalltalk by Richard J. Prinz

[stepharo]

+ 1
and it is on pharo weekly :)


Le 23/3/15 22:17, Sven Van Caekenberghe a écrit :

I hadn't seen this posted on the mailing list, but this is really cool stuff.

Using Google service discovery API's with Pharo Smalltalk by Richard J. Prinz


   http://www.min.at/prinz/?x=entry:entry150318-104537 


Nice work, Richard !

Sven

Re: [Pharo-users] Collection with memory?

[stepharo]

Le 25/3/15 09:32, Sven Van Caekenberghe a écrit :

OK, I get your point now, #read and #read: are a better combination than #get 
and #read:

About #++ and friends, yes I think they are so uncommon that they do not 
warrant a special selector, what is the point ?


do not let creep in bad ideas!
I can tell you from a dyslexic point of view

i++
++i
and all cryptic things that makes a programmer feels like a real 
men is not fun.


Let us use them carefully not as "look mum I can do it"

Stef



On 25 Mar 2015, at 09:12, stepharo  wrote:


Stef,

Like Denis said, there is no #next: in Xtreams, AFIACT.

Yes but this is the same
we should get  read and read: and not get and read:
This is my point.

There are

XTReadStream>>#get
   "Read an object from self.
If there aren't any elements left in the stream, the Incomplete exception is 
raised."

and

XTReadStream>>#read: anInteger
   "Read anInteger's worth of elements from self and return them in a 
collection.
If full anInteger number of elements cannot be read from the source, the 
Incomplete exception is raised."

Like I said, these selector names were chosen to prevent confusion, on purpose. 
I think that is good. I also think that a lot of though went into the design.

I personally think that
get and read: are bad and irregular.

XTReadStream>>#read
  "Read an object from self.
   If there aren't any elements left in the stream, the Incomplete exception is 
raised."

XTReadStream>>#read: anInteger
  "Read anInteger's worth of elements from self and return them in a collection.
   If full anInteger number of elements cannot be read from the source, the 
Incomplete exception is raised."


funny how the comments are good. No need to change them. This is a sign.

Re: [Pharo-users] USB in Pharo?

[stepharo]

Le 24/3/15 15:58, Udo Schneider a écrit :

I guess not :-)

I'll try to wrap libUSB then.

I assume the future-proof way to use "a" FFI framework is to use the 
NB notation? Do I remember correctly that the NB notation is supposed 
to remain the same although the backend will change to something more 
like traditional FFI?


Yes


So using NB notation w/o relying on the code generation is safe, correct?


Yes!


CU,

Udo


On 23.03.2015 16:15, Udo Schneider wrote:

All,

does anybody have some code or plugin to access USB ports with Pharo?
Maybe something using libUSB or OpenUSB?

Thanks,

Udo

[Pharo-users] GRNumberPrinter

[Cameron Sanders via Pharo-users]

--- Begin Message ---
What am i doing wrong here with my usage?

(GRNumberPrinter new separator: $,; precision: 2; yourself)
print:  -300.

when inspected i get '300.00'.

Thanks in advance.

-Cam
--- End Message ---

Re: [Pharo-users] GRNumberPrinter

[Sven Van Caekenberghe]

According to GRPrinterTest>>#testIntegerPrinter this is expected behaviour ;-)

There is also a GRSignPrinter, but since there are no class comments ...

> On 25 Mar 2015, at 20:14, Cameron Sanders via Pharo-users 
>  wrote:
> 
> 
> Date: 25 Mar 2015 20:13:59 CET
> Subject: GRNumberPrinter
> From: Cameron Sanders 
> To: Any question about pharo is welcome 
> 
> 
> 
> What am i doing wrong here with my usage?
> 
> (GRNumberPrinter new separator: $,; precision: 2; yourself) 
>   print:  -300.
> 
> when inspected i get '300.00'.
> 
> Thanks in advance.
> 
> -Cam
> 
> 

Re: [Pharo-users] Settings browser

[Hilaire]

Le 25/03/2015 15:04, Hilaire a écrit :
> Le 25/03/2015 12:39, Alain Plantec via Pharo-users a écrit :
>>> settingInputWidgetForNode: aSettingDeclaration
>>>^ (aSettingDeclaration name, 'Widget') asSymbol value: self.
>>>
>> strange that you send the #value: message to a Symbol here.
>> Alain
> It is tricky indeed, but it is the only way I found to by-pass the
> limitation for customized widget:
> as I understood it, settings browser expects one class (a type) per
> dedicated widget. I can latter create a dedicated class for each drop
> list morph I need in the settings browser, then remove this strange
> by-pass, I am still exploring.
> Nevertheless, it does not seem related to the model problem I exposed
> previously.
>
> Thanks
>
> Hilaire
>
As I wrote previously, the Settings browser let me complete almost
successfully what I need. See attached screenshot. I am only stuck with
widget model explicitly set to the SettingDeclaration.

Thanks

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

Re: [Pharo-users] [Pharo-dev] The Grapher charting engine

[Tudor Girba]

Hi Alex,

After the Pharo and Moose release I will get back to you with feedback.

Cheers,
Doru


On Fri, Mar 20, 2015 at 10:18 PM, Alexandre Bergel 
wrote:

> Dear all,
>
> As many of you know, Grapher is a über-cool charting engine, part of
> Roassal.
> For people who do not know what Grapher is, here is a (compelling we hope)
> example:
>
> Which is obtained by the following script:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> | b colors points ds pts dec lb |
> b := RTGrapher new.
> colors := Array with: Color red with: Color blue.
> points := OrderedCollection new.
>
> colors do: [ :c |
> ds := RTStackedDataSet new.
> pts := ((1 to: 100) collect: [ :i | 50 atRandom - 25 ]) cumsum.
> points add: pts.
> ds points: pts.
> dec := RTDevVarDecorator new.
> dec moveBehind;
> desviation: 0.5;
> color: (c alpha: 0.3);
> points: pts.
> ds connectUsing: (RTLine new color: (c alpha: 0.5); width: 1 ).
> b add: ds.
> b addDecorator: dec.
>  ].
>
> b axisX; axisY.
> b build.
>
> lb := RTLegendBuilder new.
> lb view: b view.
> colors doWithIndex: [ :c :i |
> lb addColor: c text: 'Series  ', i printString ].
> lb build.
> b view @ RTZoomableView.
> b view
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
> In our grand vision of making Roassal the best visualizing engine of the
> Universe (we also know to be modest time to time, but not today :-),
> Grapher will play a very important role. We would like to stabilize Grapher
> and make it sure it happily fits everybody needs. You can help on it:
>
> - When you are tempted to look at the dark side of the planet (this is
> where R, JFreeChart, gnuplot, D3 and all their friends live), let us know.
> We will make sure to make you are happy again.
>
> - Share your wishlist with us. We already have a long todo list, but your
> opinion does matter and will take it seriously
>
> - we are open to contributions, which could be financial, bug fixe,
> enhancement, or simply encouragement.
>
> I am very happy to be surrounded by very smart engineers. Your
> encouragement are making them happy :-)
>
> Cheers,
> Alexandre, in the name of the Object Profile Team
>
> NB: sorry for the cross-list posting, but this email is very important for
> us, and for you we hope.
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [Pharo-dev] The Grapher charting engine

[Alexandre Bergel]

Thanks!

Alexandre 


> Le 25 mars 2015 à 17:53, Tudor Girba  a écrit :
> 
> Hi Alex,
> 
> After the Pharo and Moose release I will get back to you with feedback.
> 
> Cheers,
> Doru
> 
> 
>> On Fri, Mar 20, 2015 at 10:18 PM, Alexandre Bergel  
>> wrote:
>> Dear all,
>> 
>> As many of you know, Grapher is a über-cool charting engine, part of Roassal.
>> For people who do not know what Grapher is, here is a (compelling we hope) 
>> example:
>> 
>> Which is obtained by the following script:
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> | b colors points ds pts dec lb |
>> b := RTGrapher new.
>> colors := Array with: Color red with: Color blue.
>> points := OrderedCollection new.
>> 
>> colors do: [ :c |
>>  ds := RTStackedDataSet new.
>>  pts := ((1 to: 100) collect: [ :i | 50 atRandom - 25 ]) cumsum.
>>  points add: pts.
>>  ds points: pts.
>>  dec := RTDevVarDecorator new.
>>  dec moveBehind;
>>  desviation: 0.5;
>>  color: (c alpha: 0.3);
>>  points: pts.
>>  ds connectUsing: (RTLine new color: (c alpha: 0.5); width: 1 ).
>>  b add: ds.
>>  b addDecorator: dec.
>>   ].
>> 
>> b axisX; axisY.
>> b build.
>> 
>> lb := RTLegendBuilder new.
>> lb view: b view.
>> colors doWithIndex: [ :c :i | 
>>  lb addColor: c text: 'Series  ', i printString ].
>> lb build.
>> b view @ RTZoomableView.
>> b view
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> 
>> 
>> In our grand vision of making Roassal the best visualizing engine of the 
>> Universe (we also know to be modest time to time, but not today :-), Grapher 
>> will play a very important role. We would like to stabilize Grapher and make 
>> it sure it happily fits everybody needs. You can help on it:
>> 
>>  - When you are tempted to look at the dark side of the planet (this is 
>> where R, JFreeChart, gnuplot, D3 and all their friends live), let us know. 
>> We will make sure to make you are happy again.
>> 
>>  - Share your wishlist with us. We already have a long todo list, but 
>> your opinion does matter and will take it seriously
>>  
>>  - we are open to contributions, which could be financial, bug fixe, 
>> enhancement, or simply encouragement.
>> 
>> I am very happy to be surrounded by very smart engineers. Your encouragement 
>> are making them happy :-)
>> 
>> Cheers,
>> Alexandre, in the name of the Object Profile Team
>> 
>> NB: sorry for the cross-list posting, but this email is very important for 
>> us, and for you we hope.
>> 
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
> 
> 
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"

Re: [Pharo-users] Settings browser

[Alain Plantec via Pharo-users]

--- Begin Message ---
Hello Hilaire,
I will have a look, I don’t remember why.
btw, I have to check because the #respondsTo: is not very sexy.
Cheers
Alain


> As I wrote previously, the Settings browser let me complete almost
> successfully what I need. See attached screenshot. I am only stuck with
> widget model explicitly set to the SettingDeclaration.
> 
> Thanks
> 
> -- 
> Dr. Geo - http://drgeo.eu 
> iStoa - http://istoa.drgeo.eu 
> 
> 

--- End Message ---

[Pharo-users] MongoTalk and Replica Sets

[p...@highoctane.be]

For serious use of MongoDB, there is a need to support replica sets.

At this point, the MongoClient doesn't appear to support much more
than a simple mongod instance.

Is there support for that anywhere ?

(leaving behind the requirements for supporting GridFS and bulk operations).

Python and Node drivers do have support for these. Maybe someone
ported parts of them to Pharo?

TIA
Phil

[Pharo-users] Serving static content

[Silvia Ruiz Diaz]

Hi all!

I'm new to Pharo and I'm trying to generate links to be able to serve some
files. This is what I have so far.


html anchor url:'http://localhost:8080/myApp/myFile'; with: 'Link'


When clicking on any of the generated links I'm getting redirected to the
application homepage, so I'm wondering if is there any additional setup I
have to take care of in order to grant access to these files.

My OS is Windows 64.

Thanks in advance!

Regards!

Re: [Pharo-users] Serving static content

[jtuc...@objektfabrik.de]

Silvia,


The URL you provide in the link points to the application, and without 
any additional configuration (see below) what you see is expected behaviour.


Seaside doesn't serve files per default. There are two thing you can do

a) setup an http server like apache or nginx to serve files from some 
directory and add links to that server to your application


b) implement a subclass of WAFileLibrary, import the files you want to 
server from within your Smalltalk image into that FileLibrary and 
register it with your application. That way your Smalltalk image works 
like a classical http server for the files you added.


For both alternatives, I guess it is best to search the web, because 
that would be too long a description for a mailing list. Not that they 
are complicated.


Joachim

Am 26.03.15 um 00:40 schrieb Silvia Ruiz Diaz:

Hi all!

I'm new to Pharo and I'm trying to generate links to be able to serve 
some files. This is what I have so far.



html anchor url:'http://localhost:8080/myApp/myFile'; with: 'Link'


When clicking on any of the generated links I'm getting redirected to 
the application homepage, so I'm wondering if is there any additional 
setup I have to take care of in order to grant access to these files.


My OS is Windows 64.

Thanks in advance!

Regards!

Re: [Pharo-users] Serving static content

[Hernán Morales Durand]

Hi Silvia,

You don't need Seaside or Iliad, to serve static content. In the
Configuration Browser (I guess you are using Pharo 3 at least) you can
select KomHttpServer, Install, and then evaluate the following expression:

| ma |
ma := ModuleAssembly core.
ma documentRoot: FileSystem disk workingDirectory fullName.
ma directoryIndex: 'index.html index.htm'.
ma serveFiles.
(HttpService startOn: 8080 named: 'Example') plug: ma rootModule

Finally browse to http://localhost:8080

Cheers,

Hernán



2015-03-25 20:40 GMT-03:00 Silvia Ruiz Diaz :

> Hi all!
>
> I'm new to Pharo and I'm trying to generate links to be able to serve some
> files. This is what I have so far.
>
>
> html anchor url:'http://localhost:8080/myApp/myFile'; with: 'Link'
>
>
> When clicking on any of the generated links I'm getting redirected to the
> application homepage, so I'm wondering if is there any additional setup I
> have to take care of in order to grant access to these files.
>
> My OS is Windows 64.
>
> Thanks in advance!
>
> Regards!
>

Re: [Pharo-users] Serving static content

[Sven Van Caekenberghe]

Using Zinc this becomes something like:

ZnServer startDefaultOn: 1701.

ZnServer default delegate: (
  (ZnStaticFileServerDelegate new) 
 prefixFromString: 'apple/macosx'; 
 directory: '/Library/WebServer/Documents' asFileReference; 
 yourself).

http://localhost:1701/apple/macoxs/

> On 26 Mar 2015, at 06:00, Hernán Morales Durand  
> wrote:
> 
> Hi Silvia,
> 
> You don't need Seaside or Iliad, to serve static content. In the 
> Configuration Browser (I guess you are using Pharo 3 at least) you can select 
> KomHttpServer, Install, and then evaluate the following expression:
> 
> | ma |
> ma := ModuleAssembly core.
> ma documentRoot: FileSystem disk workingDirectory fullName.
> ma directoryIndex: 'index.html index.htm'.
> ma serveFiles.
> (HttpService startOn: 8080 named: 'Example') plug: ma rootModule
> 
> Finally browse to http://localhost:8080
> 
> Cheers,
> 
> Hernán
> 
> 
> 
> 2015-03-25 20:40 GMT-03:00 Silvia Ruiz Diaz :
> Hi all!
> 
> I'm new to Pharo and I'm trying to generate links to be able to serve some 
> files. This is what I have so far.
> 
> 
> html anchor url:'http://localhost:8080/myApp/myFile'; with: 'Link'
> 
> 
> When clicking on any of the generated links I'm getting redirected to the 
> application homepage, so I'm wondering if is there any additional setup I 
> have to take care of in order to grant access to these files.
> 
> My OS is Windows 64.
> 
> Thanks in advance!
> 
> Regards!
>