[Pharo-users] How to export critics from Critic Browser?

[Hernán Morales Durand]

Hi,

I'm using Pharo 6.1 and I want to export a report of Critics Browser results.
Is there a way to save the results?

It would be nice to have a CSV, to record historical analysis of my
progress, then plot using Roassal, etc.

Cheers,

Hernán

[Pharo-users] Spotter question. "Spotter" search keyword need font setting from Pharo Setting Value.

[peter yoo]

I'm korean user. pharo using mac or linux.

I'm always change font setting. because want look korean characters(so
simple)

but can't using spotter. GLMRubTextFieldMorph font value have hard coding
inside.(maybe... look a "SourceSansPro". my pharo using another font now.)

spotter result is ok. because GLMScrollPaneBandBrick font value from "Pharo
Setting Value".

how can change spotter keyword font value? I'm newbie. detail explanation
request please. I want fix and understand.

thanks to pharo community. always :D

-- 
http://lookandwalk.com  http://looknw.com | http://onionmixer.net
peter yoo(Jonghwa Yoo). ROK

Re: [Pharo-users] Performance of zero conf install since 6.1 seems very slow?

[Tim Mackinnon]

Actually its all over the place - the times vary from seconds (like it used to 
work) to 5-10 mins. It’s not very reliable - so. I hope it can be fixed 
(although it does seem that the image download is usually the one I’ve noticed 
to slow down dramatically). I’m still trying to sort out some caching on my end 
to hopefully lessen the impact of this down stream where my CI lives.

Tim

> On 31 Jul 2017, at 00:12, Tim Mackinnon  wrote:
> 
> I’m still seeing very slow download response times - so I’ve started to work 
> on better caching Inria downloads in my build script - however in doing this, 
> I notice that its not the VM that takes time to download (its as quick as 
> always) its the image? e.g. (http://files.pharo.org/get-files/61/pharo64.zip 
> )
> 
> Why would this file take so much longer than than the vm? (As in minutes vs. 
> Seconds)
> 
> Tim
> 
>> On 26 Jul 2017, at 12:59, Tim Mackinnon > > wrote:
>> 
>> Yes I see the same - it was seconds and now minutes.
>> 
>> Maybe it is worth having a mirror for CI (or does it get edge cached anyway- 
>> probably not from what we are seeing, but possibly if could be?)
>> 
>> Tim
>> 
>> Sent from my iPhone
>> 
>> On 26 Jul 2017, at 09:17, Esteban Lorenzano > > wrote:
>> 
>>> it may been related to recent INRIA infrastructure changes. 
>>> there is nothing 6.1 itself can do with that (6.1 is just a bunch of zips)
>>> 
>>> Esteban
>>> 
 On 26 Jul 2017, at 09:44, Guillermo Polito >>> > wrote:
 
 We were also seeing it yesterday. In travis, 10m to download an image (and 
 thus timeout). Before it took seconds.
 
 On Wed, Jul 26, 2017 at 9:41 AM, Denis Kudriashov >>> > wrote:
 Hi.
 
 I don't know answer. But what time it takes before? 
 
 2017-07-26 9:30 GMT+02:00 Tim Mackinnon >>> >:
 Hi - has anyone else noticed that since 6.1 - using zero conf for installs 
 is very very slow (it takes minutes to download pharo64.zip when using
 
 curl get.pharo.org/64/  | bash
 
 This is both on my local computer but also on the gitlab ci server? Is it 
 possibly something isn’t configured right?
 
 Tim
 
 
 
 
 -- 

 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
>>> 
> 

[Pharo-users] Threads safety in Pharo

[Alidra Abdelghani via Pharo-users]

--- Begin Message ---
Hi,

Somebody once evoked the problem of threads safety in Pharo. With a friend of 
mine who is expert in formal methods and process scheduling, we would like to 
have a look on it.
Does anyone knows a good document describing the problem of Pharo with threads 
safety or at least any document that we can start with?

Thanks in advance,
Abdelghani


--- End Message ---

Re: [Pharo-users] Performance of zero conf install since 6.1 seems very slow?

[Tim Mackinnon]

I’m still seeing very slow download response times - so I’ve started to work on 
better caching Inria downloads in my build script - however in doing this, I 
notice that its not the VM that takes time to download (its as quick as always) 
its the image? e.g. (http://files.pharo.org/get-files/61/pharo64.zip)

Why would this file take so much longer than than the vm? (As in minutes vs. 
Seconds)

Tim

> On 26 Jul 2017, at 12:59, Tim Mackinnon  wrote:
> 
> Yes I see the same - it was seconds and now minutes.
> 
> Maybe it is worth having a mirror for CI (or does it get edge cached anyway- 
> probably not from what we are seeing, but possibly if could be?)
> 
> Tim
> 
> Sent from my iPhone
> 
> On 26 Jul 2017, at 09:17, Esteban Lorenzano  > wrote:
> 
>> it may been related to recent INRIA infrastructure changes. 
>> there is nothing 6.1 itself can do with that (6.1 is just a bunch of zips)
>> 
>> Esteban
>> 
>>> On 26 Jul 2017, at 09:44, Guillermo Polito >> > wrote:
>>> 
>>> We were also seeing it yesterday. In travis, 10m to download an image (and 
>>> thus timeout). Before it took seconds.
>>> 
>>> On Wed, Jul 26, 2017 at 9:41 AM, Denis Kudriashov >> > wrote:
>>> Hi.
>>> 
>>> I don't know answer. But what time it takes before? 
>>> 
>>> 2017-07-26 9:30 GMT+02:00 Tim Mackinnon >> >:
>>> Hi - has anyone else noticed that since 6.1 - using zero conf for installs 
>>> is very very slow (it takes minutes to download pharo64.zip when using
>>> 
>>> curl get.pharo.org/64/  | bash
>>> 
>>> This is both on my local computer but also on the gitlab ci server? Is it 
>>> possibly something isn’t configured right?
>>> 
>>> Tim
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>>
>>> 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] Pharo Seaside RESTful services pragma question

[Greg Hutchinson]

Thanks Johan - that link looks very helpful.


On 30 July 2017 at 02:21, Johan Brichau  wrote:

> The Seaside book REST chapter should be deprecated or changed.
>
> Take a look here for the updated info: https://github.com/
> SeasideSt/Seaside/wiki/Seaside-REST
>
> Johan
>
>
> On 30 Jul 2017, at 01:46, Greg Hutchinson 
> wrote:
>
> That worked - thanks very much.
>
> On 29 July 2017 at 16:13, Esteban A. Maringolo 
> wrote:
>
>> Did you try setting the pragma  in the list method?
>> Esteban A. Maringolo
>>
>>
>> 2017-07-28 18:40 GMT-03:00 Greg Hutchinson > >:
>> > I am new to Pharo/Seaside and it has been a long time since I have used
>> > Smalltalk. I am trying to make a RESTful service and can’t get the
>> pragmas
>> > to work the way I think it should. (This might be the problem already).
>> >
>> >
>> >
>> >  Ie Here is my list method within class TeamMembers which is a direct
>> > subclass of WARestfulHandler.
>> >
>> > list
>> >
>> >
>> >
>> >   ^ String streamContents: [ :stream |
>> >
>> >self teamMembers do: [ :each |
>> >
>> >stream nextPutAll: each ; crlf ]
>> >
>> >]
>> >
>> >
>> >
>> > and
>> >
>> >
>> >
>> > listJson
>> >
>> > 
>> >
>> > 
>> >
>> >
>> >
>> >^ (Array streamContents: [ :stream |
>> >
>> >   self teamMembers do: [ :each |
>> >
>> >  stream nextPut: (Dictionary new
>> >
>> > at: 'name' put: each ;
>> >
>> > yourself) ] ])
>> >
>> >   asJavascript
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > After doing all the proper registration WAAdmin register: TeamMembers
>> at:
>> > 'team-members' when I execute in the browser
>> > (http://localhost:8080/team-members) I received the message
>> >
>> > /team-members not found
>> > but if I execute (http://localhost:8080/team-members/list), it brings
>> back
>> > the team member list. (However, I didn’t think I would have to add
>> /list to
>> > the URL).
>> >
>> >
>> >
>> > This seems to contradict the documentation in
>> > http://book.seaside.st/book/advanced/restful/getting-started
>> /define-handler.
>> >
>> >
>> >
>> >
>> >
>> > However, If I override the TeamMembers>>
>> >
>> > createRoutes
>> >
>> > | route pType|
>> >
>> > pType := WAFullMimeTypeMatch main:'text' sub: 'json' .
>> >
>> > route := WASimpleRoute method: 'GET' selector: #listJson
>> > produces: pType consumes: WAWildcardMimeTypeMatch new.
>> >
>> > ^ OrderedCollection new
>> >
>> > "GET"
>> >
>> > add: route;
>> >
>> > add: (WARoute get: #list);
>> >
>> > yourself.
>> >
>> >
>> >
>> > Then I get the expected behaviour when I browse to
>> > (http://localhost:8080/team-members) and using curl. (ie.
>> >
>> > curl -H "Accept: text/json" http://localhost:8080/team-members
>> >
>> > to get the Json response.
>> >
>> >
>> >
>> > When I debug the difference in the routes, it looks like using the
>> pragmas,
>> > I get WAComplexRoute(s) but of course in the overridden method
>> createRoutes,
>> > I get WASimpleRoutes.
>> >
>> >
>> >
>> > Is this the way it is supposed to work?
>> >
>> >
>> >
>> >
>> >
>> > Thanks in advance for any hints.
>> >
>>
>>
>
>
> --
>
>
>


--

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[peter yoo]

congratulation !!!

2017-07-26 0:50 GMT+09:00 Esteban Lorenzano :

>
> On 25 Jul 2017, at 17:29, Hilaire  wrote:
>
> As the P6.1 change log is not complete enough I have to try out to
> discover:
>
> - fix for PNG regression is included
>
> - the Athen Wrap regression is still present :(
>
>
> is very complete. Is just that it does not has so many changes :)
> this was a version we told it was going to be made available to update
> iceberg (as we use iceberg for develop P7, we need to have recurrent
> updates even in Pharo 6). And since there was important modifications, we
> needed to change the backend library. And since we changed the backend
> library, we needed to change the vm. Finally, since we changed the VM, we
> were unable to apply this update as a “hot-fix” (what we do regularly, but
> version number does not change, just build number).
>
> So, Pharo 6.1 is exactly the same as before, but with: new iceberg, new
> vm, new backend library.
>
> cheers!
> Esteban
>
> ps: the other regressions, when fixed, can be applied as we usual apply
> backported hot-fixes.
>
>
> Le 25/07/2017 à 08:59, Hilaire a écrit :
>
> Meaning these tow ones ?
>
> http://forum.world.st/Regression-with-PNGReaderWriter-in-P6-
> td4951796.html#a4952046
>
> http://forum.world.st/WrapAthen-World-coordinate-td4951750.html#a4951966
>
>
> --
> Dr. Geohttp://drgeo.eu
>
>
>


-- 
http://lookandwalk.com  http://looknw.com | http://onionmixer.net
peter yoo(Jonghwa Yoo). ROK

Re: [Pharo-users] Pharo 61 crashes on iceberg history

[herby]

Me, too. Primitive failure. 117, IIRC.

On July 30, 2017 3:51:56 AM GMT+02:00, "Julián Maestri"  
wrote:
>I'm almost sure this is not the right place to report it.
>
>Im having a vm crash when looking at the history of a repository on
>iceberg.
>
>urpharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top
>(av)
>> && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE &&
>prev_inuse
>> (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)'
>failed.
>> ./pharo-ui: line 11:  2011 Aborted (core dumped)
>> "$DIR"/"pharo-vm/pharo" "$@"
>>
>
>Pharo downloaded from get.pharo.org/64/ on Ubuntu 16.04 (64bit)
>
>Has somebody had this problem?
>Where's the right place to report this?
>
>Thanks, Julián

Re: [Pharo-users] STON question

[Stephane Ducasse]

> First question is, why do anything at all ?
>
>   STON toStringPretty: 
>
> Then loading is as simple as
>
>   STON fromString: '...'

I know :)
Now I wanted to overuse STON to be able to edit manually the file too.


> Next step is to customise how STON output is generated (but again, why ?).
>
> You do that by writing both an #stonOn: and a #fromSton: method (look for 
> implementors for examples).
>
> If you really want, you could get something like:
>
> GameCollector [
> GameItem {
> #name : 'Final Fantasy X',
> #console : #PS2,
> #hasDocumentation : false,
> #hasBox : true,
> #finished : true,
> #condition : 'Good',
> #quotation : 10,
> #critics : 18,
> #comments : 'quite cool in fact'
> },
> GameItem {
> #name : 'Final Fantasy XII',
> #console : '',
> #hasDocumentation : true,
> #hasBox : false,
> #finished : false,
> #condition : 'Good',
> #quotation : 10,
> #critics : 15,
> #comments : ''
> }
> ]
>
> to work.
>
> Something like (untested):
>
> GameCollector>>stonOn: stonWriter
> stonWriter writeObject: self do: [
> stonWriter encodeList: self items ]
>
> GameCollector class>>fromSton: stonReader
> | collector |
> collector := self new.
> stonReader parseListDo: [ :each |
> collector addGameItem: each ].
> ^ collector

Thanks this is what I was looking for. :)

Re: [Pharo-users] NeoJSON "conditional" parsing/mapping

[Esteban A. Maringolo]

2017-07-26 18:36 GMT-03:00 Sven Van Caekenberghe :
> Esteban,
>
> I had a quick look at the spec you mentioned.
>
> I am a bit puzzled though. Result can be anything, so how are you going to 
> map that to specific classes (and why) ?
> That would require serious prior knowledge and even then, not every situation 
> can be mapped easily to a class

Since I'm going to use it in the context of RPC calls, I can know
beforehand what kind of class is the result, so I want to leverage
that knowledge to avoid going through an intermediate Dictionary/map
to build the object.

> You speak about subclassing NeoJSONObject, which is cool, because it is so 
> flexible, but then why type it further ?
> If I were you, I would at least start the easy/lazy way.
> For example you could do
>   NeoJSONObject fromString: '...'
> And see how far you get. If things get slow, I would look for alternatives.

Yeap... I took your advice after making things unnecessarily complex...
after the first... and second attempt.
I tried to make a client too smart and early optimize for things I
haven't used before,
so I ended up making stuff convoluted (I'm specialist).

Long story short, I almost ended up where I started, which was a fork of
LtRpcJsonClient, with some minor fixes, using NeoJSON instead of the
JSON package for parsing/writing and using NeoJSONObject as mapClass,
named: NeoJSONRPCClient [1]

I'm using it to build a particular client that uses JSON-RPC, so most
of my specific needs were moved/implemented in my still unfinished
client subclass, if behavior becomes abstract enough, I can push it up
to the "general purpose" client.

I didn't skip the build of the map object, but for my domain specific
classes I pass the map to my specific instances, so each instance
holds a reference to the map object used to build it. I didn't feel
comfortable subclassing domain specific classes from Dictionary.

Regards!

Esteban A. Maringolo

[1] It's available at https://github.com/eMaringolo/NeoJSONRPC but I'm
still learning how to do Baselines and other stuff to work with this
pet-project I'm using to learn Iceberg. So the baseline doesn't
work... yet :|

Re: [Pharo-users] Looking for small boards and tiny computers which can run Pharo

[Steven Costiou]

Hi, 

thanks everybody for all the leads. I will look into all those :) 

Steven. 

Le 2017-07-25 19:11, Bruce O'Neel a écrit :

> Hi, 
> 
> With a bit of work it probably fits on one of these: 
> 
> https://onion.io/omega2/ 
> 
> If you feel on really wasting space this would work as well, though it would 
> need some porting if you wanted to run it locally. 
> 
> https://getchip.com/pages/pocketchip 
> 
> If you don't want the display and keyboard and want to run it remote this 
> will work then, it's the CPU from the above. 
> 
> https://getchip.com/pages/chip 
> 
> If I get some free time I can poke at these and see how well Squeak etc runs. 
> 
> cheers 
> 
> bruce 
> 
> _24 July 2017 21:30 Steven Costiou  wrote:_ 
> 
>> Hi, 
>> 
>> i am looking for: 
>> 
>> - small hardware, boards/computers, "embeddable" devices, etc. that can run 
>> Pharo (except Raspberry pi that i already know) 
>> 
>> - robots, flying drones or things alike with an open linux which can 
>> possibly run Pharo 
>> 
>> Could somebody points me to documentation or web sites where such things can 
>> be found ? 
>> 
>> Thanks, 
>> 
>> Steven.
 

[Pharo-users] Pharo launcher on Linux Mint

[Sebastian Heidbrink via Pharo-users]

--- Begin Message ---

Hi!

I used Pharo launcher on Windows and Ubuntu before and never had any 
troubles.


Now, I am trying to used it on Linux Mint without success.

Once I start the freshly created image the appropriate VM is downloaded 
but the image is not started.


A PharoDebug.log is created in the image folder complaining that it 
can't find the PharoVXX.sources files in the 
"pharo/bin/lib/pharo/5.0-201707201942" folder.


After I copy the missing file into that folder the image is still not 
opened and no further logs are created or updated.


A downloaded Pharo.zip from the Pharo website opens just fine.

Is this a known issue?

Thank you!

Sebastian

--- End Message ---

Re: [Pharo-users] STON question

[Sven Van Caekenberghe]

First question is, why do anything at all ?

  STON toStringPretty: 

Then loading is as simple as

  STON fromString: '...'

Next step is to customise how STON output is generated (but again, why ?).

You do that by writing both an #stonOn: and a #fromSton: method (look for 
implementors for examples).

If you really want, you could get something like:

GameCollector [
GameItem {
#name : 'Final Fantasy X',
#console : #PS2,
#hasDocumentation : false,
#hasBox : true,
#finished : true,
#condition : 'Good',
#quotation : 10,
#critics : 18,
#comments : 'quite cool in fact'
},
GameItem {
#name : 'Final Fantasy XII',
#console : '',
#hasDocumentation : true,
#hasBox : false,
#finished : false,
#condition : 'Good',
#quotation : 10,
#critics : 15,
#comments : ''
}
]

to work.

Something like (untested):

GameCollector>>stonOn: stonWriter
stonWriter writeObject: self do: [
stonWriter encodeList: self items ]

GameCollector class>>fromSton: stonReader
| collector |
collector := self new.
stonReader parseListDo: [ :each |
collector addGameItem: each ].
^ collector

> On 30 Jul 2017, at 17:39, Stephane Ducasse  wrote:
> 
> Hi sven
> 
> I'm coding with my son a game collector application :)
> We want to save our collection with STON
> 
> So far we have
> 
> GameCollector asSTON >>
> 
> String streamContents: [ :s | STON put: self onStreamPretty: s ]
> 
> and we get
> 
> GameCollector {
> #items : OrderedCollection [
> GameItem {
> #name : 'Final Fantasy X',
> #console : #PS2,
> #hasDocumentation : false,
> #hasBox : true,
> #finished : true,
> #condition : 'Good',
> #quotation : 10,
> #critics : 18,
> #comments : 'quite cool in fact'
> },
> GameItem {
> #name : 'Final Fantasy XII',
> #console : '',
> #hasDocumentation : true,
> #hasBox : false,
> #finished : false,
> #condition : 'Good',
> #quotation : 10,
> #critics : 15,
> #comments : ''
> }
> ]
> }
> 
> And this is good.
> Now I wanted to use STON to save the items without the class structure
> 
> to get something like
> 
> OrderedCollection [
> GameItem {
> #name : 'Final Fantasy X',
> #console : #PS2,
> #hasDocumentation : false,
> #hasBox : true,
> #finished : true,
> #condition : 'Good',
> #quotation : 10,
> #critics : 18,
> #comments : 'quite cool in fact'
> },
> GameItem {
> #name : 'Final Fantasy XII',
> #console : '',
> #hasDocumentation : true,
> #hasBox : false,
> #finished : false,
> #condition : 'Good',
> #quotation : 10,
> #critics : 15,
> #comments : ''
> }
> ]
> 
> 
> I coded as
> 
> GameCollector >> asSTON
> 
> ^ String streamContents: [ :s | STON put: items onStreamPretty: s ]
> 
> and STON is not happy on reload.
> 
> I know that we are bending the rules.
> Is there a way to do simply what I want?
> 
> I could leave also with
> 
> GameItem {
> #name : 'Final Fantasy X',
> #console : #PS2,
> #hasDocumentation : false,
> #hasBox : true,
> #finished : true,
> #condition : 'Good',
> #quotation : 10,
> #critics : 18,
> #comments : 'quite cool in fact'
> },
> GameItem {
> #name : 'Final Fantasy XII',
> #console : '',
> #hasDocumentation : true,
> #hasBox : false,
> #finished : false,
> #condition : 'Good',
> #quotation : 10,
> #critics : 15,
> #comments : ''
> }
> 
> Stef
> 

Re: [Pharo-users] STON question

[Cyril Ferlicot D.]

Le 30/07/2017 à 17:39, Stephane Ducasse a écrit :
> Hi sven
> 
> I'm coding with my son a game collector application :)
> We want to save our collection with STON
> 
> So far we have
> 
> GameCollector asSTON >>
> 
>  String streamContents: [ :s | STON put: self onStreamPretty: s ]
> 
> and we get
> 
> GameCollector {
> #items : OrderedCollection [
> GameItem {
> #name : 'Final Fantasy X',
> #console : #PS2,
> #hasDocumentation : false,
> #hasBox : true,
> #finished : true,
> #condition : 'Good',
> #quotation : 10,
> #critics : 18,
> #comments : 'quite cool in fact'
> },
> GameItem {
> #name : 'Final Fantasy XII',
> #console : '',
> #hasDocumentation : true,
> #hasBox : false,
> #finished : false,
> #condition : 'Good',
> #quotation : 10,
> #critics : 15,
> #comments : ''
> }
> ]
> }
> 
> And this is good.
> Now I wanted to use STON to save the items without the class structure
> 
> to get something like
> 
> OrderedCollection [
> GameItem {
> #name : 'Final Fantasy X',
> #console : #PS2,
> #hasDocumentation : false,
> #hasBox : true,
> #finished : true,
> #condition : 'Good',
> #quotation : 10,
> #critics : 18,
> #comments : 'quite cool in fact'
> },
> GameItem {
> #name : 'Final Fantasy XII',
> #console : '',
> #hasDocumentation : true,
> #hasBox : false,
> #finished : false,
> #condition : 'Good',
> #quotation : 10,
> #critics : 15,
> #comments : ''
> }
> ]
> 
> 
> I coded as
> 
> GameCollector >> asSTON
> 
>  ^ String streamContents: [ :s | STON put: items onStreamPretty: s ]
> 
> and STON is not happy on reload.
> 
> I know that we are bending the rules.
> Is there a way to do simply what I want?
> 
> I could leave also with
> 
> GameItem {
> #name : 'Final Fantasy X',
> #console : #PS2,
> #hasDocumentation : false,
> #hasBox : true,
> #finished : true,
> #condition : 'Good',
> #quotation : 10,
> #critics : 18,
> #comments : 'quite cool in fact'
> },
> GameItem {
> #name : 'Final Fantasy XII',
> #console : '',
> #hasDocumentation : true,
> #hasBox : false,
> #finished : false,
> #condition : 'Good',
> #quotation : 10,
> #critics : 15,
> #comments : ''
> }
> 
> Stef
> 

Hi,

Maybe you can just create a new GameCollector on the reading.

"protocol: instance-creation"
GameCollector class>>importFromFile: aFile

  ^ self new
items: (STON fromString: aFile contents);
yourself



-- 
Cyril Ferlicot
https://ferlicot.fr

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



signature.asc
Description: OpenPGP digital signature

[Pharo-users] STON question

[Stephane Ducasse]

Hi sven

I'm coding with my son a game collector application :)
We want to save our collection with STON

So far we have

GameCollector asSTON >>

 String streamContents: [ :s | STON put: self onStreamPretty: s ]

and we get

GameCollector {
#items : OrderedCollection [
GameItem {
#name : 'Final Fantasy X',
#console : #PS2,
#hasDocumentation : false,
#hasBox : true,
#finished : true,
#condition : 'Good',
#quotation : 10,
#critics : 18,
#comments : 'quite cool in fact'
},
GameItem {
#name : 'Final Fantasy XII',
#console : '',
#hasDocumentation : true,
#hasBox : false,
#finished : false,
#condition : 'Good',
#quotation : 10,
#critics : 15,
#comments : ''
}
]
}

And this is good.
Now I wanted to use STON to save the items without the class structure

to get something like

OrderedCollection [
GameItem {
#name : 'Final Fantasy X',
#console : #PS2,
#hasDocumentation : false,
#hasBox : true,
#finished : true,
#condition : 'Good',
#quotation : 10,
#critics : 18,
#comments : 'quite cool in fact'
},
GameItem {
#name : 'Final Fantasy XII',
#console : '',
#hasDocumentation : true,
#hasBox : false,
#finished : false,
#condition : 'Good',
#quotation : 10,
#critics : 15,
#comments : ''
}
]


I coded as

GameCollector >> asSTON

 ^ String streamContents: [ :s | STON put: items onStreamPretty: s ]

and STON is not happy on reload.

I know that we are bending the rules.
Is there a way to do simply what I want?

I could leave also with

GameItem {
#name : 'Final Fantasy X',
#console : #PS2,
#hasDocumentation : false,
#hasBox : true,
#finished : true,
#condition : 'Good',
#quotation : 10,
#critics : 18,
#comments : 'quite cool in fact'
},
GameItem {
#name : 'Final Fantasy XII',
#console : '',
#hasDocumentation : true,
#hasBox : false,
#finished : false,
#condition : 'Good',
#quotation : 10,
#critics : 15,
#comments : ''
}

Stef

Re: [Pharo-users] Iceberg and removing packages

[Esteban A. Maringolo]

I got into the pharo-local/iceberg/... and git rm'ed the directory,
commited and synchronized the project in Iceberg.

I hope it doesn't break anything since I don't know how much "magic"
does Iceberg behind the scenes other than automating the git commands
and providing a centralized UI.

What is the "This is all you need to read to understand Iceberg?"
document I should read? I read its wiki, but it seems there is more to
go.

Regards!

Esteban A. Maringolo


2017-07-30 11:28 GMT-03:00 Peter Uhnak :
> This was supposedly fixed in April 
> https://github.com/pharo-vcs/iceberg/issues/317
>
> however I had the same issue ~two months ago, so I had to delete the packages 
> by hand.
>
> P
>
>
> On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote:
>> Hi,
>>
>> I'm playing around with Iceberg in Pharo 6, and even when I find the
>> workflow streamlined, but since it doesn't map 1:1 with git workflow
>> from other IDEs or command line, I find myself not knowing how to do
>> certain tasks.
>>
>> One thing that happened is that I published a few packages to one of
>> my repos in Github, then I decided to remove one of the packages from
>> the repo, then I synchronized it but in the repo there is still is the
>> package folder for the package I removed.
>>
>> What should I do to definitely remove those files from the commit?
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>

Re: [Pharo-users] Iceberg and removing packages

[Peter Uhnak]

This was supposedly fixed in April 
https://github.com/pharo-vcs/iceberg/issues/317

however I had the same issue ~two months ago, so I had to delete the packages 
by hand.

P


On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote:
> Hi,
> 
> I'm playing around with Iceberg in Pharo 6, and even when I find the
> workflow streamlined, but since it doesn't map 1:1 with git workflow
> from other IDEs or command line, I find myself not knowing how to do
> certain tasks.
> 
> One thing that happened is that I published a few packages to one of
> my repos in Github, then I decided to remove one of the packages from
> the repo, then I synchronized it but in the repo there is still is the
> package folder for the package I removed.
> 
> What should I do to definitely remove those files from the commit?
> 
> Regards!
> 
> Esteban A. Maringolo
> 

Re: [Pharo-users] Pharo 61 crashes on iceberg history

[Stephane Ducasse]

Thanks Julian
Esteban is on vacation right now. But this is the right place.
Thanks again.

On Sun, Jul 30, 2017 at 3:51 AM, Julián Maestri  wrote:
> I'm almost sure this is not the right place to report it.
>
> Im having a vm crash when looking at the history of a repository on iceberg.
>
>> urpharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top (av)
>> && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse
>> (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
>> ./pharo-ui: line 11:  2011 Aborted (core dumped)
>> "$DIR"/"pharo-vm/pharo" "$@"
>
>
> Pharo downloaded from get.pharo.org/64/ on Ubuntu 16.04 (64bit)
>
> Has somebody had this problem?
> Where's the right place to report this?
>
> Thanks, Julián

Re: [Pharo-users] Pharo Seaside RESTful services pragma question

[Stephane Ducasse]

Argh I will try to migrate it to Pillar for real.

On Sun, Jul 30, 2017 at 10:21 AM, Johan Brichau  wrote:

> The Seaside book REST chapter should be deprecated or changed.
>
> Take a look here for the updated info: https://github.com/
> SeasideSt/Seaside/wiki/Seaside-REST
>
> Johan
>
>
> On 30 Jul 2017, at 01:46, Greg Hutchinson 
> wrote:
>
> That worked - thanks very much.
>
> On 29 July 2017 at 16:13, Esteban A. Maringolo 
> wrote:
>
>> Did you try setting the pragma  in the list method?
>> Esteban A. Maringolo
>>
>>
>> 2017-07-28 18:40 GMT-03:00 Greg Hutchinson > >:
>> > I am new to Pharo/Seaside and it has been a long time since I have used
>> > Smalltalk. I am trying to make a RESTful service and can’t get the
>> pragmas
>> > to work the way I think it should. (This might be the problem already).
>> >
>> >
>> >
>> >  Ie Here is my list method within class TeamMembers which is a direct
>> > subclass of WARestfulHandler.
>> >
>> > list
>> >
>> >
>> >
>> >   ^ String streamContents: [ :stream |
>> >
>> >self teamMembers do: [ :each |
>> >
>> >stream nextPutAll: each ; crlf ]
>> >
>> >]
>> >
>> >
>> >
>> > and
>> >
>> >
>> >
>> > listJson
>> >
>> > 
>> >
>> > 
>> >
>> >
>> >
>> >^ (Array streamContents: [ :stream |
>> >
>> >   self teamMembers do: [ :each |
>> >
>> >  stream nextPut: (Dictionary new
>> >
>> > at: 'name' put: each ;
>> >
>> > yourself) ] ])
>> >
>> >   asJavascript
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > After doing all the proper registration WAAdmin register: TeamMembers
>> at:
>> > 'team-members' when I execute in the browser
>> > (http://localhost:8080/team-members) I received the message
>> >
>> > /team-members not found
>> > but if I execute (http://localhost:8080/team-members/list), it brings
>> back
>> > the team member list. (However, I didn’t think I would have to add
>> /list to
>> > the URL).
>> >
>> >
>> >
>> > This seems to contradict the documentation in
>> > http://book.seaside.st/book/advanced/restful/getting-started
>> /define-handler.
>> >
>> >
>> >
>> >
>> >
>> > However, If I override the TeamMembers>>
>> >
>> > createRoutes
>> >
>> > | route pType|
>> >
>> > pType := WAFullMimeTypeMatch main:'text' sub: 'json' .
>> >
>> > route := WASimpleRoute method: 'GET' selector: #listJson
>> > produces: pType consumes: WAWildcardMimeTypeMatch new.
>> >
>> > ^ OrderedCollection new
>> >
>> > "GET"
>> >
>> > add: route;
>> >
>> > add: (WARoute get: #list);
>> >
>> > yourself.
>> >
>> >
>> >
>> > Then I get the expected behaviour when I browse to
>> > (http://localhost:8080/team-members) and using curl. (ie.
>> >
>> > curl -H "Accept: text/json" http://localhost:8080/team-members
>> >
>> > to get the Json response.
>> >
>> >
>> >
>> > When I debug the difference in the routes, it looks like using the
>> pragmas,
>> > I get WAComplexRoute(s) but of course in the overridden method
>> createRoutes,
>> > I get WASimpleRoutes.
>> >
>> >
>> >
>> > Is this the way it is supposed to work?
>> >
>> >
>> >
>> >
>> >
>> > Thanks in advance for any hints.
>> >
>>
>>
>
>
> --
>
>
>

Re: [Pharo-users] Critical issues for Dr. Geo on P6

[Stephane Ducasse]

Hilaire

We were discussing this with Esteban and he will do a stab at making
sure that we can
deploy desktop applications much easier with Pharo. Because we need it.
Esteban deployed several desktop apps in the past and we should
leverage this knowledge.
I also wants to write this in a forthcoming tutorial.

Stef

On Sun, Jul 30, 2017 at 4:20 PM, Stephane Ducasse
 wrote:
> + 100
>
> On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe  wrote:
>>
>>> On 28 Jul 2017, at 15:13, p...@highoctane.be wrote:
>>>
>>> Changing too many things at once is indeed annoying.
>>>
>>> Now, I am ready to live with that but at one point, I think that we will 
>>> have to move to something like I see done in other fast evolving ecosystems.
>>>
>>> In Hadoop for example, Hortonworks (a distribution) moved to a set of slow 
>>> evolving substrate that is stable and know to stay stable for a long period 
>>> (HDFS, YARN) and a set fast moving releases for projects that do build on 
>>> top (Spark).
>>>
>>> Holding back on the new things makes you feel like you use a tool of the 
>>> past. Living on the bleeding edge is not doable because you need to solve 
>>> too many non business centric issues.
>>>
>>> There needs to be a combination.
>>>
>>> As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 
>>> ship, embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not 
>>> develop production code on it at the moment. 7.0 looks okay but there are 
>>> lot of changing things there, so, that is also too much for me.
>>>
>>> 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on 
>>> large collections. I need a platform I can understand and build upon.
>>>
>>> There needs to be a semblance of LTS in this.
>>
>> But even the LTS concept does not solve all problems.
>>
>> Every 2 years there is a new LTS, which is supported for 5 years.
>>
>> But in most projects (the same happened here), you are lazy and wait 5 years 
>> until you *have* to upgrade.
>>
>> And by then the difference between what you started with (say 12.04) and the 
>> current stable (say 16.04) can already be huge (remember, you skipped one 
>> LTS release) and the next one is already coming (18.04).
>>
>> Change is unavoidable, it is not just part of life, it *is* life.
>>
>>> Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not.
>>>
>>> 6.x is a great platform and has a lot going for it if stable enough.
>>>
>>> I have projects coming my way and using Pharo is an option. Now, I need 
>>> something that is not going to shift under my feet.
>>>
>>> Especially if I want to embark crew along.
>>>
>>> Phil
>>>
>>> On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich 
>>>  wrote:
>>>
>>>
>>> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire  wrote:
>>> I don't share your enthusiasm.
>>>
>>> I once set up a satisfactory build environment for DrGeo, based on P3. As 
>>> long as I stay with P3, I can concentrate on DrGeo code: write the code, 
>>> then fire up a build script to deploy the application. Now porting to P6 is 
>>> a pain: the infrastructure to deploy a desktop application has not evolve 
>>> since P3, I have to build again a deployment environment from scratch (VM 
>>> support, shrinked/built image, I don't know the promise of minimal image 
>>> build up is not palpable for me).
>>>
>>> Now If I have to spend days on that, I am not sure I will do it again, I 
>>> can't compete against other geometry application if I have to fight against 
>>> pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry 
>>> to make it explicit but I can't much offer to do both.
>>>
>>>
>>> I have sometimes the same concerns with Pharo or some tools of the Pharo 
>>> ecosystem. I know that we are trying to do our best and regarding the 
>>> number of core developers we have already an incredible platform. But 
>>> sometimes, you need to very simple updates and because of subtle problems 
>>> with VM/configurations/CI/ etc ...  this is not that simple and we need to 
>>> spend times on boring stuff.
>>>
>>> There is no simple solution.
>>>
>>> One solution might be that the core developers only focus on core Pharo 
>>> functionalities but I think this is somewhat difficult, because most of the 
>>> dev are from RMOD. RMOD is a research unit and could not spend all his 
>>> money/effort on an engineering process.
>>>
>>> Another solution is to grow our community. More people, more companies to 
>>> sustain more engineers through the consortium. The more people we are able 
>>> to attract, the more people will help to develop working solutions for 
>>> problems like deployment or to have bug-fixing intermediate releases.
>>>
>>> This is why we all need in the community to do as much as possible 
>>> advertisements: lectures at universities, talk to your colleague about 
>>> Pharo, do demos in companies, at open-source forums, use Twitter do talk 
>>> about Pharo ecosystem, the software you are developing with Pharo.

Re: [Pharo-users] Critical issues for Dr. Geo on P6

[Stephane Ducasse]

+ 100

On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe  wrote:
>
>> On 28 Jul 2017, at 15:13, p...@highoctane.be wrote:
>>
>> Changing too many things at once is indeed annoying.
>>
>> Now, I am ready to live with that but at one point, I think that we will 
>> have to move to something like I see done in other fast evolving ecosystems.
>>
>> In Hadoop for example, Hortonworks (a distribution) moved to a set of slow 
>> evolving substrate that is stable and know to stay stable for a long period 
>> (HDFS, YARN) and a set fast moving releases for projects that do build on 
>> top (Spark).
>>
>> Holding back on the new things makes you feel like you use a tool of the 
>> past. Living on the bleeding edge is not doable because you need to solve 
>> too many non business centric issues.
>>
>> There needs to be a combination.
>>
>> As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship, 
>> embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop 
>> production code on it at the moment. 7.0 looks okay but there are lot of 
>> changing things there, so, that is also too much for me.
>>
>> 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large 
>> collections. I need a platform I can understand and build upon.
>>
>> There needs to be a semblance of LTS in this.
>
> But even the LTS concept does not solve all problems.
>
> Every 2 years there is a new LTS, which is supported for 5 years.
>
> But in most projects (the same happened here), you are lazy and wait 5 years 
> until you *have* to upgrade.
>
> And by then the difference between what you started with (say 12.04) and the 
> current stable (say 16.04) can already be huge (remember, you skipped one LTS 
> release) and the next one is already coming (18.04).
>
> Change is unavoidable, it is not just part of life, it *is* life.
>
>> Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not.
>>
>> 6.x is a great platform and has a lot going for it if stable enough.
>>
>> I have projects coming my way and using Pharo is an option. Now, I need 
>> something that is not going to shift under my feet.
>>
>> Especially if I want to embark crew along.
>>
>> Phil
>>
>> On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich 
>>  wrote:
>>
>>
>> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire  wrote:
>> I don't share your enthusiasm.
>>
>> I once set up a satisfactory build environment for DrGeo, based on P3. As 
>> long as I stay with P3, I can concentrate on DrGeo code: write the code, 
>> then fire up a build script to deploy the application. Now porting to P6 is 
>> a pain: the infrastructure to deploy a desktop application has not evolve 
>> since P3, I have to build again a deployment environment from scratch (VM 
>> support, shrinked/built image, I don't know the promise of minimal image 
>> build up is not palpable for me).
>>
>> Now If I have to spend days on that, I am not sure I will do it again, I 
>> can't compete against other geometry application if I have to fight against 
>> pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry 
>> to make it explicit but I can't much offer to do both.
>>
>>
>> I have sometimes the same concerns with Pharo or some tools of the Pharo 
>> ecosystem. I know that we are trying to do our best and regarding the number 
>> of core developers we have already an incredible platform. But sometimes, 
>> you need to very simple updates and because of subtle problems with 
>> VM/configurations/CI/ etc ...  this is not that simple and we need to spend 
>> times on boring stuff.
>>
>> There is no simple solution.
>>
>> One solution might be that the core developers only focus on core Pharo 
>> functionalities but I think this is somewhat difficult, because most of the 
>> dev are from RMOD. RMOD is a research unit and could not spend all his 
>> money/effort on an engineering process.
>>
>> Another solution is to grow our community. More people, more companies to 
>> sustain more engineers through the consortium. The more people we are able 
>> to attract, the more people will help to develop working solutions for 
>> problems like deployment or to have bug-fixing intermediate releases.
>>
>> This is why we all need in the community to do as much as possible 
>> advertisements: lectures at universities, talk to your colleague about 
>> Pharo, do demos in companies, at open-source forums, use Twitter do talk 
>> about Pharo ecosystem, the software you are developing with Pharo.
>> Don't hide problems but talk about our nice platform and our community.
>>
>> We have done this with Stephane in the early days of Pharo at open-source 
>> forums in France and I remember that you come in the community after we meet 
>> you in one of these forums :-)
>> So DrGeo2 exists because of this kind of advertisement.
>>
>> Regards,
>>
>> --
>> Serge Stinckwich
>> UCN & UMI UMMISCO 209 (IRD/UPMC)
>> Every DSL ends up being Smalltalk
>> http://www.doesnotundersta

Re: [Pharo-users] Critical issues for Dr. Geo on P6

[Stephane Ducasse]

We understand that perfectly. Now for us we get money now and may be
not the same in the future.
Then there are the things that
  - must be done and consume a lot: 64bits, uFFI,
  - super important to do git
  - also super important: cleaning and improving the system.
So we pay attention for backward compatibilities but we cannot cover
everything.

Stef

On Fri, Jul 28, 2017 at 3:13 PM, p...@highoctane.be  wrote:
> Changing too many things at once is indeed annoying.
>
> Now, I am ready to live with that but at one point, I think that we will
> have to move to something like I see done in other fast evolving ecosystems.
>
> In Hadoop for example, Hortonworks (a distribution) moved to a set of slow
> evolving substrate that is stable and know to stay stable for a long period
> (HDFS, YARN) and a set fast moving releases for projects that do build on
> top (Spark).
>
> Holding back on the new things makes you feel like you use a tool of the
> past. Living on the bleeding edge is not doable because you need to solve
> too many non business centric issues.
>
> There needs to be a combination.
>
> As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship,
> embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop
> production code on it at the moment. 7.0 looks okay but there are lot of
> changing things there, so, that is also too much for me.
>
> 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large
> collections. I need a platform I can understand and build upon.
>
> There needs to be a semblance of LTS in this.
>
> Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not.
>
> 6.x is a great platform and has a lot going for it if stable enough.
>
> I have projects coming my way and using Pharo is an option. Now, I need
> something that is not going to shift under my feet.
>
> Especially if I want to embark crew along.
>
> Phil
>
> On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich
>  wrote:
>>
>>
>>
>> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire  wrote:
>>>
>>> I don't share your enthusiasm.
>>>
>>> I once set up a satisfactory build environment for DrGeo, based on P3. As
>>> long as I stay with P3, I can concentrate on DrGeo code: write the code,
>>> then fire up a build script to deploy the application. Now porting to P6 is
>>> a pain: the infrastructure to deploy a desktop application has not evolve
>>> since P3, I have to build again a deployment environment from scratch (VM
>>> support, shrinked/built image, I don't know the promise of minimal image
>>> build up is not palpable for me).
>>>
>>> Now If I have to spend days on that, I am not sure I will do it again, I
>>> can't compete against other geometry application if I have to fight against
>>> pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry
>>> to make it explicit but I can't much offer to do both.
>>
>>
>> I have sometimes the same concerns with Pharo or some tools of the Pharo
>> ecosystem. I know that we are trying to do our best and regarding the number
>> of core developers we have already an incredible platform. But sometimes,
>> you need to very simple updates and because of subtle problems with
>> VM/configurations/CI/ etc ...  this is not that simple and we need to spend
>> times on boring stuff.
>>
>> There is no simple solution.
>>
>> One solution might be that the core developers only focus on core Pharo
>> functionalities but I think this is somewhat difficult, because most of the
>> dev are from RMOD. RMOD is a research unit and could not spend all his
>> money/effort on an engineering process.
>>
>> Another solution is to grow our community. More people, more companies to
>> sustain more engineers through the consortium. The more people we are able
>> to attract, the more people will help to develop working solutions for
>> problems like deployment or to have bug-fixing intermediate releases.
>>
>> This is why we all need in the community to do as much as possible
>> advertisements: lectures at universities, talk to your colleague about
>> Pharo, do demos in companies, at open-source forums, use Twitter do talk
>> about Pharo ecosystem, the software you are developing with Pharo.
>> Don't hide problems but talk about our nice platform and our community.
>>
>> We have done this with Stephane in the early days of Pharo at open-source
>> forums in France and I remember that you come in the community after we meet
>> you in one of these forums :-)
>> So DrGeo2 exists because of this kind of advertisement.
>>
>> Regards,
>>
>> --
>> Serge Stinckwich
>> UCN & UMI UMMISCO 209 (IRD/UPMC)
>> Every DSL ends up being Smalltalk
>> http://www.doesnotunderstand.org/
>
>

[Pharo-users] Iceberg and removing packages

[Esteban A. Maringolo]

Hi,

I'm playing around with Iceberg in Pharo 6, and even when I find the
workflow streamlined, but since it doesn't map 1:1 with git workflow
from other IDEs or command line, I find myself not knowing how to do
certain tasks.

One thing that happened is that I published a few packages to one of
my repos in Github, then I decided to remove one of the packages from
the repo, then I synchronized it but in the repo there is still is the
package folder for the package I removed.

What should I do to definitely remove those files from the commit?

Regards!

Esteban A. Maringolo

[Pharo-users] Job for Spec & Roassal?

[David Epstein]

Hello,


I've been reading over the documentation and want to try my first project with 
Pharo. The project will begin as a simple diagramming program for making logic 
models.
 Are there any similar projects or demos I should look at? As I progress with 
Pharo, I intend for the diagram elements to carry a lot of built-in 
functionality and data for program evaluation. Would I build the interface with 
Spec and the diagramming elements with Roassal? So, clicking a Spec button 
would create a Roassal object?


-david

Re: [Pharo-users] Pharo Seaside RESTful services pragma question

[Johan Brichau]

The Seaside book REST chapter should be deprecated or changed.

Take a look here for the updated info: 
https://github.com/SeasideSt/Seaside/wiki/Seaside-REST 


Johan

> On 30 Jul 2017, at 01:46, Greg Hutchinson  
> wrote:
> 
> That worked - thanks very much.
> 
> On 29 July 2017 at 16:13, Esteban A. Maringolo  > wrote:
> Did you try setting the pragma  in the list method?
> Esteban A. Maringolo
> 
> 
> 2017-07-28 18:40 GMT-03:00 Greg Hutchinson  >:
> > I am new to Pharo/Seaside and it has been a long time since I have used
> > Smalltalk. I am trying to make a RESTful service and can’t get the pragmas
> > to work the way I think it should. (This might be the problem already).
> >
> >
> >
> >  Ie Here is my list method within class TeamMembers which is a direct
> > subclass of WARestfulHandler.
> >
> > list
> >
> >
> >
> >   ^ String streamContents: [ :stream |
> >
> >self teamMembers do: [ :each |
> >
> >stream nextPutAll: each ; crlf ]
> >
> >]
> >
> >
> >
> > and
> >
> >
> >
> > listJson
> >
> > 
> >
> > 
> >
> >
> >
> >^ (Array streamContents: [ :stream |
> >
> >   self teamMembers do: [ :each |
> >
> >  stream nextPut: (Dictionary new
> >
> > at: 'name' put: each ;
> >
> > yourself) ] ])
> >
> >   asJavascript
> >
> >
> >
> >
> >
> >
> >
> > After doing all the proper registration WAAdmin register: TeamMembers at:
> > 'team-members' when I execute in the browser
> > (http://localhost:8080/team-members ) I 
> > received the message
> >
> > /team-members not found
> > but if I execute (http://localhost:8080/team-members/list 
> > ), it brings back
> > the team member list. (However, I didn’t think I would have to add /list to
> > the URL).
> >
> >
> >
> > This seems to contradict the documentation in
> > http://book.seaside.st/book/advanced/restful/getting-started/define-handler 
> > .
> >
> >
> >
> >
> >
> > However, If I override the TeamMembers>>
> >
> > createRoutes
> >
> > | route pType|
> >
> > pType := WAFullMimeTypeMatch main:'text' sub: 'json' .
> >
> > route := WASimpleRoute method: 'GET' selector: #listJson
> > produces: pType consumes: WAWildcardMimeTypeMatch new.
> >
> > ^ OrderedCollection new
> >
> > "GET"
> >
> > add: route;
> >
> > add: (WARoute get: #list);
> >
> > yourself.
> >
> >
> >
> > Then I get the expected behaviour when I browse to
> > (http://localhost:8080/team-members ) 
> > and using curl. (ie.
> >
> > curl -H "Accept: text/json" http://localhost:8080/team-members 
> > 
> >
> > to get the Json response.
> >
> >
> >
> > When I debug the difference in the routes, it looks like using the pragmas,
> > I get WAComplexRoute(s) but of course in the overridden method createRoutes,
> > I get WASimpleRoutes.
> >
> >
> >
> > Is this the way it is supposed to work?
> >
> >
> >
> >
> >
> > Thanks in advance for any hints.
> >
> 
> 
> 
> 
> -- 
>