March 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] UI Frameworks

by Konrad Hinsen

Bob Cowdery <bob(a)bobcowdery.plus.com> writes: > I also found Block and Brick which say they are next generation, Block > being for graphics andÂ Brick for widgets. These are not yet in Pharo > and again I couldn't find any info although there is a tutorial for > Block but not for Brick. Having forgotten most everything I knew I > didn't have much success trying to run the Brick examples. The best existing illustration of what you can do with Bloc and Bric is probably GToolkit: https://gtoolkit.com/. It also serves as a warning that this is not ready for prime time yet. For example, the current version crashes Pharo rather quickly if you use native windows. It isn't a tutorial either, of course, but a huge reservoir of examples. So an important consideration is your development time scale. If you have a deadline for a usable product, better don't bet on Bloc and Bric yet. Konrad.

March 13, 2019

Re: [Pharo-users] Hmmm sending at:put: to an undefined object (nil) gives a confusing error message

by K K Subbu

On 12/03/19 9:25 AM, Richard O'Keefe wrote: > Squeak where (20 factorial at: 1) answers 0 (oh dear oh dear oh > dear). Richard, Could you please elaborate on why this is an error? Large integers are place value encoded (base 256 little endian) and stored in byte arrays, so they need #at:/#at:put: (as private methods). Place value encoding is not architecture-specific so it doesn't affect portability of an image. Regards .. Subbu

March 13, 2019

PharoLauncher Baseline Templates

by Ben Coman

Recently I was asked about moving personal projects between images to keep up with latest Pharo 8 development version. My suggestion was of course creating a Baseline to load into each fresh Image. This morning I was contemplating that further and what would be cool is in PharoLauncher being able to right-click a template and have a list of favourite Baselines I could install e.g. BaselineMyProject. Perhaps even be able to define Baseline-Templates that auto-recreate every time the Baseline version moves, so I don't have to wait for all the dependencies to be pulled in. This is just a a seed of an idea and I'm seeking feedback to flesh it out. Could be a useful GSoC project? cheers -ben

March 13, 2019

[ANN] CouchDB Client for Pharo

by Esteban Maringolo

Hello all, I finished polishing the repository a CouchDB client for Pharo that I forked from an old, and seemingly abandoned, client for VisualWorks. I took that code and refactored heavily to use Pharo and Zinc core classes, and that included renaming the client classes, methods and the strategy used to map objects to/from JSON. It is available at: https://github.com/eMaringolo/pharo-couchdb I'm open to questions or suggestions about this or how to use it. Disclaimer: This is mostly experimental since I'm not using it in production and was done as a means of exploration of CouchDB itself for a project I'm prospecting. There are a lot of features that could be added to the client, and things that could be refactored further (such as the class side request methods), but adding that is simple, and the current state provides almost feature complete coverage. Best regards, Esteban A. Maringolo

March 13, 2019

Re: [Pharo-users] complex json parsing.

by Ben Coman

On Wed, 13 Mar 2019 at 04:59, Roelof Wobben <r.wobben(a)home.nl> wrote: > Op 11-3-2019 om 00:03 schreef Ben Coman: > > getMoreData "or a better name of your own" > | url json artObjectJson | > url := 'https://www.rijksmuseum.nl/api/nl/collection/' , > objectNumber , '?key=[API_KEY]&format=json' > Transcript crShow: 'Getting description from ', url. > json := (NeoJSONReader fromString: (ZnEasy get: url) contents). > artObjectJson := json at: 'artObject. > description := artObjectJson at: 'description'. > title := artObjectJson at: 'title'. > > > > hello Ben, > > I think I almost see what you mean but still one problem > > when doing this code : > > collectionUrl := ' > https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… > '. > json := NeoJSONReader fromString: (ZnEasy get: collectionUrl) contents. > paintings := Paintings fromJSON: json. > paintings do: [:painting | painting getMoreData ] > > here I see a error : instance of Paintings do not understand do: > > I think we have to get the directory named paintings out of the object, > > > this seems to be working : > > collectionUrl := ' > https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… > '. > json := NeoJSONReader fromString: (ZnEasy get: collectionUrl) contents. > paintings := Paintings fromJSON: json. > (paintings paintings) do: [:painting | painting getMoreData ] > You are right. An alternative fix is... Paintings >> do: aBlock ^ paintings do: aBlock cheers -ben

March 13, 2019

Re: [Pharo-users] complex json parsing.

by Ben Coman

On Wed, 13 Mar 2019 at 02:10, Roelof Wobben <r.wobben(a)home.nl> wrote: > Op 12-3-2019 om 18:46 schreef Ben Coman: > > Then in Playground do... > collectionUrl := ' > https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… > '. > json := NeoJSONReader fromString: (ZnEasy get: collectionUrl) contents. > paintings := Paintings fromJSON: json. > paintings inspect. > > and then debug trace through that whole thing. > Is that what you were trying to do? Or have I got the wrong end of the > stick? > > cheers -ben > > > There is a one to one relationship between the objectNumber and a Painting > > I do not use the imageUrl found on this url because it's to big . > okay. So I presume you want "artObject/webImage/url" ? { "artObject": { "webImage": { "url": " http://lh6.ggpht.com/wwx2vAS9DzFmmyeZefPjMtmCNOdjD80gvkXJcylloy40SiZOhdLHVd… " > > So what I try now is first put all the objectNumber in a collection > and use that collection on a second url to fetch a image of the right size > Okay. I understand, but I am *still* coaching you to *not* do that. Rather than gathering a collection of dumb numbers and then creating new Painting objects from those, (which is awkward for joining the new data with the previous data) work with the Painting objects you already have. Add a new instance variables "webImageUrl" and "webImage" Then either Painting >> getMoreData |entity| ... webImageUrl := (artObjectJson at: 'webImage') at: 'url'. entity := (ZnEasy get: webImageUrl) entity. webImage := ImageReadWriter formFromStream: entity readStream. which may lock the UI for a moment downloading them all, or download lazily (slight variation on my previous imageEntity which doubles up on storage)... Painting >> getMoreData ... webImageUrl := (artObjectJson at: 'webImage') at: 'url'. Painting >> webImage |entity| webImageUrl ifNil: [^nil]. webImage ifNil: [ entity := (ZnEasy get: webImageUrl) entity. webImage := ImageReadWriter formFromStream: entity readStream]. ^ webImage Painting >> gtInspectorJpegIn: composite <gtInspectorPresentationOrder: 0> composite morph title: 'Painting'; display: [ self webImage ] > I hope im clear what I try to do in this step > yes it is. Please take my coaching and kill your collection of numbers. Keeping them keeps you stuck in old ways of thinking. So just kill it :) Once you've done that, alternatives will open up for you and you'll be on the path to a new way of thinking about programming. :) :) > so numbers should be a collection of objectNumbers > no. > and paintings a collection of painting with the info I need > yes, and objectNumber is part of the info of a painting. > > so to recap > > this one must give me a collection of objectNumbers : ' > https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… > '. > no. it gives you a collection of paintings, of which objectNumber is one attribute. > > and the objectNumbers I can use for this url : > > https://www.rijksmuseum.nl/api/nl/collection/<one objectNumber/tiles?key=14OGzuak&format=json > > and I do not store the objectNumber in Paintings because I do not use it to display it in a seaside project. > > Regardless of whether you display it or not, objectNumber is supplied by the server "as an attribute belonging to painting" so store it inside your Painting objects. Then rather than Seaside asking a collection of dumb numbers for each JPEG to display it asks a collection of smart Painting objects for their JPEG to display (since they know their own objectNumber, they can get the JPEG themselves). cheers -ben On Wed, 13 Mar 2019 at 02:10, Roelof Wobben <r.wobben(a)home.nl> wrote: > Op 12-3-2019 om 18:46 schreef Ben Coman: > > On Wed, 13 Mar 2019 at 00:43, Roelof Wobben <r.wobben(a)home.nl> wrote: > > I did try to make this idea work but now im complete lost. > > > > Right now the collection that should contain the objectNumbers is total > empty > > anyone who can see where I went wrong. > > > > I included my code so far. > > > A few things... > !Paintings class methodsFor: 'instance creation' stamp: 'RoelofWobben > 3/12/2019 17:26'! > getImagesDataFromJSON: json > | instance | > instance := Painting new. > (json at: #values) > do: [ :artObjectJson | > | painting | > painting := Painting new. > painting imageUrl: (json at: #name). > instance addPainting: painting ]. > ^ instance! ! > > You are adding a painting to a painting, which semantically makes no sense. > i.e. where #addPainting: is sent to "instance" , that is holding a > Painting. > > I would not expect your Painting class to have a method addPainting: > Paintings should have that method. > > btw, Stop using "instance" as a variable name. > Its as bad as variables named "a", "i", "t", "z" - it provides no semantic > context. > > -------------------- > Object subclass: #Paintings > instanceVariableNames: 'paintings numbers' > > Paintings class > instanceVariableNames: 'numbers paintings'! > > You've defined these variables on both the instance-side and class-side. > I'll hazard a guess that you should delete the class-side definition. > > ---------------------------------- > > TBApplicationRootComponent initialize!Object subclass: #Painting > instanceVariableNames: 'imageUrl' > > Why are you *not* storing objectNumber inside each Painting? > What is the relationship between paintings and objectNumbers? > Is it one-to-many or one-to-one? > > ------------------- > !Paintings methodsFor: 'instance creation' stamp: 'RoelofWobben 3/11/2019 > 08:05'! > initialize > super initialize. > numbers := OrderedCollection new! ! > > Why do you *not* initialize variable "paintings" to "OrderedCollection > new" ? > Aren't you dealing with a collection of paintings? > > ---------------- > There is lots more confusing me here, so before going further, > in a fresh new image, can you load NeoJSON and the attached fileout. > > Then in Playground do... > collectionUrl := ' > https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… > '. > json := NeoJSONReader fromString: (ZnEasy get: collectionUrl) contents. > paintings := Paintings fromJSON: json. > paintings inspect. > > and then debug trace through that whole thing. > Is that what you were trying to do? Or have I got the wrong end of the > stick? > > cheers -ben > > > > Oke, I try to tell what I want > > Right now I only want to fetch the objectNumber is a collection. > > so I can use that in a later step. > > There is a one to one relationship between the objectNumber and a Painting > > I do not use the imageUrl found on this url because it's to big . > > So what I try now is first put all the objectNumber in a collection > and use that collection on a second url to fetch a image of the right size > > I hope im clear what I try to do in this step > > so numbers should be a collection of objectNumbers and paintings a > collection of painting with the info I need > > so to recap > > this one must give me a collection of objectNumbers : ' > https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… > '. > > and the objectNumbers I can use for this url : > > https://www.rijksmuseum.nl/api/nl/collection/<one objectNumber/tiles?key=14OGzuak&format=json > > and I do not store the objectNumber in Paintings because I do not use it to display it in a seaside project. > > Roelof > > >

March 13, 2019

Re: [Pharo-users] Hmmm sending at:put: to an undefined object (nil) gives a confusing error message

by Richard O'Keefe

Putting public methods in Object that it cannot honestly support makes #respondsTo: pretty unreliable. It is an obsolete practice, because having Traits means that those methods can be mixed in with (part of) a single line. On Wed, 13 Mar 2019 at 03:20, Ben Coman <btc(a)openinworld.com> wrote: > On Tue, 12 Mar 2019 at 21:56, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > Hi, > > > > Yes, I do not like itâ¦ I think it is there so that you can just make a > variable subclass and at: / at:put: will work without > > having to re-implement themâ¦ > > So we should consider... > * how often are variable subclasses created ? by novices or experts ? > * how much work is it to reimplement those methods ? how difficult to > know what needs to be done ? > * what is the balance > > cheers -ben > > > > > > Marcus > > > > On 12 Mar 2019, at 04:55, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > I understand #basicAt:[put:] being in Object, but I never understood > #at:[put:] being there. > > GNU Smalltalk: > > st> nil at: 1 > > Object: nil error: Invalid value nil: object not indexable > > In my Smalltalk, you get a DNU. > > In Squeak you get a debugger window with title > > Error: instances of UndefinedObject are not indexable > > The same for Boolean, Character, and Integer, > > except Squeak where (20 factorial at: 1) answers 0 (oh dear oh dear oh > dear). > > In VW you get a "Subscript out of bounds" error, which is disappointing, > > as do true and $a, but a LargePositiveinteger gets #shouldNotImplement. > > > > > > On Tue, 12 Mar 2019 at 15:28, Tim Mackinnon <tim(a)testit.works> wrote: > >> > >> If you forget to initialise a variable which you thought was a > Dictionary - you get a confusing error message: "Error: only integers > should be used as indicesâ if you try an at:put: > >> > >> This is a consequence of having at:put: defined on Object (which is a > bit nasty) > >> > >> Should UndefinedObject at least override this and signal something a > bit more obvious? This is a common and easily done thing and we don't > support it very well. > >> > >> I just did it in some code, and was scratching my head initially until > I read the stack properly and realised it was something much simpler than I > thought I had done. > >> > >> Any thoughts on this? > > > > > >

March 12, 2019

Re: [Pharo-users] complex json parsing.

by Roelof Wobben

March 12, 2019

TelePharo in Tonel

by Torsten Bergmann

Hi Denis, would it be possible to convert TelePharo to Tonel? https://github.com/pharo-ide/TelePharo Currently one gets load problem on Windows due to long file names and Tonel would solve that. Thanks T.

March 12, 2019

Re: [Pharo-users] doWithIndex: or withIndexDo: ?

by Richard O'Keefe

Neither. No two ways about it. #keysAndValuesDo: However, seq with: seq keys do: aBlock and seq withIndexDo: aBlock do the same thing, so #withIndexDo: makes some sense. This is not my opinion alone. I'm typing this on a machine that has Squeak but not Pharo. In Squeak we find doWithIndex: elementAndIndexBlock "Use the new version with consistent naming" ^ self withIndexDo: elementAndIndexBlock "New" means since 1997. On Wed, 13 Mar 2019 at 04:27, Oleksandr Zaytsev <olk.zaytsev(a)gmail.com> wrote: > Hello, > > I am working on a new collection and this question caught my interest. > Between doWithIndex: or withIndexDo:, which do you find more logical and > why? > > Oleks >

March 12, 2019