May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] ZnEasy / UTF-8

by Sven Van Caekenberghe

> On 01 May 2015, at 15:15, volkert <volkert(a)komponentenwerkstatt.de> wrote: > > I thought UTF-8 is the default encoding in case JSON Documents, and so for the Content-Type: application/json. > > I added "setCharSetUTF8" this Teapot-Output and all works fine now. :-) Fine, but I still think this is strange, it should work by default too. But to understand what went wrong, I need an example (server+client) that I can run. > Danke, > Volkert > > Am 01.05.2015 um 14:20 schrieb Norbert Hartl: >> You need to look at the headers of the request. I would assume the sender sets an Content-Type: application/json without charset. In that moment it is uncertain what has to be done because the server needs to assume what charset it might be and this tasks seldomly works out good. >> In order to make it work set a content type of your entity this way >> >> ZnMimeType applicationJson setCharSetUTF8 >> >> Now you send a Content-Type of application/json;charset=utf-8 and the server knows which character decoder to use. That should be it. So please always assign a char set to your sending data to make it more reliable what happens on the other end. >> >> hope this helps, >> >> Norbert >>> Am 01.05.2015 um 14:13 schrieb volkert <volkert(a)komponentenwerkstatt.de>: >>> >>> I tried ZnClient new get: 'http://<removed>/api/atm/801813'; yourself and got. >>> >>> <fdchdjab.png> >>> >>> This is the Doc i see in Firefox. >>> >>> <fceagiec.png> >>> >>> The JSON is served with ZnServer / Teapot. ;-) >>> >>> Volkert >>> >>> >>> Am 01.05.2015 um 12:21 schrieb Sven Van Caekenberghe: >>>> Hi Volkert, >>>> >>>> Tip 1: use ZnClient and inspect the response in detail, more specifically to see whether the response content type specifies the encoding. >>>> >>>> ZnClient new get: ' >>>> http:// >>>> <removed>/api/atm/801813'; yourself. >>>> >>>> Tip 2: you could try to force override the default encoding using ZnDefaultCharacterEncoder (see the class comment). >>>> >>>> But recent Zn code defaults to UTF8 (see #withDefaultUTF8Decoding: and #withDefaultUTF8Encoding:). So I am curious to see the response headers. >>>> >>>> HTH, >>>> >>>> Sven >>>> >>>> >>>>> On 01 May 2015, at 11:54, volkert <volkert(a)komponentenwerkstatt.de> >>>>> wrote: >>>>> >>>>> Dear all, >>>>> >>>>> i am trying to get a JSON Document with ZnEasy. The Document is UTF-8 encoded. >>>>> >>>>> (ZnEasy get: ' >>>>> http:// >>>>> <removed>/api/atm/801813') entity string. >>>>> >>>>> <gccacjeh.png> >>>>> >>>>> Any hints? >>>>> >>>>> Volkert >>>>> >>>>> >>>>> >>> >> >

May 1, 2015

Small workshop/hackathon today and tomorrow about Pharo and Agile Visualization.

by Offray Vladimir Luna CÃ¡rdenas

Hi all, Today and tomorrow, a small group of persons will be doing a workshop/hackathon about Pharo and Agile Visualization at our local hackerspace. Details on the event are on: http://hackbo.co/hackboweb/eventos/evento/375 I will be sharing teaching materials, first impressions and questions with you about the experience, while is happening and after that. Thanks, Offray

May 1, 2015

Re: [Pharo-users] ZnEasy / UTF-8

by volkert

I thought UTF-8 is the default encoding in case JSON Documents, and so for the Content-Type: application/json. I added "setCharSetUTF8" this Teapot-Output and all works fine now. :-) Danke, Volkert Am 01.05.2015 um 14:20 schrieb Norbert Hartl: > You need to look at the headers of the request. I would assume the > sender sets an Content-Type: application/json without charset. In that > moment it is uncertain what has to be done because the server needs to > assume what charset it might be and this tasks seldomly works out good. > In order to make it work set a content type of your entity this way > > ZnMimeType applicationJson setCharSetUTF8 > > Now you send a Content-Type of application/json;charset=utf-8 and the > server knows which character decoder to use. That should be it. So > please always assign a char set to your sending data to make it more > reliable what happens on the other end. > > hope this helps, > > Norbert >> Am 01.05.2015 um 14:13 schrieb volkert >> <volkert(a)komponentenwerkstatt.de >> <mailto:volkert@komponentenwerkstatt.de>>: >> >> I tried ZnClient new get: 'http://<removed>/api/atm/801813'; yourself >> and got. >> >> <fdchdjab.png> >> >> This is the Doc i see in Firefox. >> >> <fceagiec.png> >> >> The JSON is served with ZnServer / Teapot. ;-) >> >> Volkert >> >> >> Am 01.05.2015 um 12:21 schrieb Sven Van Caekenberghe: >>> Hi Volkert, >>> >>> Tip 1: use ZnClient and inspect the response in detail, more specifically to see whether the response content type specifies the encoding. >>> >>> ZnClient new get: 'http://<removed>/api/atm/801813'; yourself. >>> >>> Tip 2: you could try to force override the default encoding using ZnDefaultCharacterEncoder (see the class comment). >>> >>> But recent Zn code defaults to UTF8 (see #withDefaultUTF8Decoding: and #withDefaultUTF8Encoding:). So I am curious to see the response headers. >>> >>> HTH, >>> >>> Sven >>> >>>> On 01 May 2015, at 11:54, volkert<volkert(a)komponentenwerkstatt.de> wrote: >>>> >>>> Dear all, >>>> >>>> i am trying to get a JSON Document with ZnEasy. The Document is UTF-8 encoded. >>>> >>>> (ZnEasy get: 'http://<removed>/api/atm/801813') entity string. >>>> >>>> <gccacjeh.png> >>>> >>>> Any hints? >>>> >>>> Volkert >>>> >>>> >> >

May 1, 2015

Re: [Pharo-users] ZnEasy / UTF-8

by Norbert Hartl

You need to look at the headers of the request. I would assume the sender sets an Content-Type: application/json without charset. In that moment it is uncertain what has to be done because the server needs to assume what charset it might be and this tasks seldomly works out good. In order to make it work set a content type of your entity this way ZnMimeType applicationJson setCharSetUTF8 Now you send a Content-Type of application/json;charset=utf-8 and the server knows which character decoder to use. That should be it. So please always assign a char set to your sending data to make it more reliable what happens on the other end. hope this helps, Norbert > Am 01.05.2015 um 14:13 schrieb volkert <volkert(a)komponentenwerkstatt.de>: > > I tried ZnClient new get: 'http:// <http:/><removed>/api/atm/801813'; yourself and got. > > <fdchdjab.png> > > This is the Doc i see in Firefox. > > <fceagiec.png> > > The JSON is served with ZnServer / Teapot. ;-) > > Volkert > > > Am 01.05.2015 um 12:21 schrieb Sven Van Caekenberghe: >> Hi Volkert, >> >> Tip 1: use ZnClient and inspect the response in detail, more specifically to see whether the response content type specifies the encoding. >> >> ZnClient new get: 'http:// <http:/><removed>/api/atm/801813'; yourself. >> >> Tip 2: you could try to force override the default encoding using ZnDefaultCharacterEncoder (see the class comment). >> >> But recent Zn code defaults to UTF8 (see #withDefaultUTF8Decoding: and #withDefaultUTF8Encoding:). So I am curious to see the response headers. >> >> HTH, >> >> Sven >> >>> On 01 May 2015, at 11:54, volkert <volkert(a)komponentenwerkstatt.de> <mailto:volkert@komponentenwerkstatt.de> wrote: >>> >>> Dear all, >>> >>> i am trying to get a JSON Document with ZnEasy. The Document is UTF-8 encoded. >>> >>> (ZnEasy get: 'http:// <http:/><removed>/api/atm/801813') entity string. >>> >>> <gccacjeh.png> >>> >>> Any hints? >>> >>> Volkert >>> >>> >> >

May 1, 2015

Re: [Pharo-users] ZnEasy / UTF-8

by volkert

I tried ZnClient new get: 'http://<removed>/api/atm/801813'; yourself and got. This is the Doc i see in Firefox. The JSON is served with ZnServer / Teapot. ;-) Volkert Am 01.05.2015 um 12:21 schrieb Sven Van Caekenberghe: > Hi Volkert, > > Tip 1: use ZnClient and inspect the response in detail, more specifically to see whether the response content type specifies the encoding. > > ZnClient new get: 'http://<removed>/api/atm/801813'; yourself. > > Tip 2: you could try to force override the default encoding using ZnDefaultCharacterEncoder (see the class comment). > > But recent Zn code defaults to UTF8 (see #withDefaultUTF8Decoding: and #withDefaultUTF8Encoding:). So I am curious to see the response headers. > > HTH, > > Sven > >> On 01 May 2015, at 11:54, volkert <volkert(a)komponentenwerkstatt.de> wrote: >> >> Dear all, >> >> i am trying to get a JSON Document with ZnEasy. The Document is UTF-8 encoded. >> >> (ZnEasy get: 'http://<removed>/api/atm/801813') entity string. >> >> <gccacjeh.png> >> >> Any hints? >> >> Volkert >> >> >

May 1, 2015

Re: [Pharo-users] RPackage extension methods using normal protocol names

by Stephan Eggermont

On 30/04/15 17:57, Ben Coman wrote: > > > On Thu, Apr 30, 2015 at 11:18 PM, Stephan Eggermont > <stephan(a)stack.nl > <mailto:stephan@stack.nl>> wrote: > Just add a conversion mapping class to the package > > To be run manually after the package is loaded in each platform ? Well, there is more that needs translation than that. You need something that can be run in a CI process. Stephan

May 1, 2015

Re: [Pharo-users] Reading rows in a database table (select * from ...)

by Sanjay Minni

Thanks Pierce - I go the drift of the loop but have actually tried it out with the odbc<->sqlite driver however in your notes below you mentioned that you used a dump of large size. My question is when faced with such large row sets how do you limit the size of data read in the select statement . Select * from table would probably read in the entire table set, and the limit clause would stop and not go beyond the no# of rows specified. another doubt I had was from the example code below from the NBSQLite3. is rs close at the right place - would it be closing the connection ? res := db beginTransaction. rs := db execute: '...'. rs close. res := db commitTransaction. regards Sanjay Pierce Ng-3 wrote > On Thu, Apr 30, 2015 at 06:29:53AM -0700, Sanjay Minni wrote: >> the smalltalkhub page shows an example >> db execute: 'SELECT * FROM BLOGPOSTS;'. >> but how are the rows supposed to be accessed - in the tests i see they >> have >> to be walked thru one by one like a 3GL loop > > Sanjay, > > Here's how you can collect all rows: > > | db resultSet row coll | > coll := OrderedCollection new. > db := NBSQLite3Connection openOn: '/tmp/so.db'. > [ resultSet := db execute: 'select * from posts limit 10'. > [ (row := resultSet next) notNil ] whileTrue: [ > coll add: row ] > ] ensure: [ db close ]. > coll inspect. > > Each row is an NBSQLite3Row instance. Use #at: with the column name as key > to get at the data. > > coll fifth at: 'Title' > ==> 'How do I calculate someone''s age in C#?' > > With the collection you still have to loop through them, no? > > I am using NBSQLite3 to play with existing data, and I haven't worked with > enough different types of data to attempt to generalize a looping > construct. So > I've always done by-row processing. > > Another reason is that, while my data sets aren't "Big Data", I am > aesthetically inclined against reading everything into RAM. :-) Above > example > uses the Sep 2011 StackOverflow data dump. The SQLite datafile created > from the > dump, with full text indexing, is 16GB and the table posts has ~6.5 > million > rows. > > HTH. > > Pierce ----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/Reading-rows-in-a-database-table-select-from-tp482300… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 1, 2015

Re: [Pharo-users] Package comments

by Marcus Denker

> On 01 May 2015, at 12:45, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > One question, is someone working this kind of metadata management? Because > 1) instead of keeping it in the class, we can keep it in objects. > 2) It can be serialized into STON for git versioning and probably it can be stored in some way in Monticello > I donât like in general to have data in methodsâ¦ For Monticello, we really should add file storage. itâs easy -> add ivar to RPackage -> annualise it lazily with an in-Memory filesystem -> on MC save, copy the files into a âresourcesâ subdirectory of the zip file. -> on load, just load the files from the âresourcesâ subdirectory into the in-memory filesystem. -> add a tool to add files to the in memory filesystem. The best here would be to add support to GTInspector to copy files â> DONE. Marcus

May 1, 2015

Re: [Pharo-users] Package comments

by Yuriy Tymchuk

One question, is someone working this kind of metadata management? Because 1) instead of keeping it in the class, we can keep it in objects. 2) It can be serialized into STON for git versioning and probably it can be stored in some way in Monticello Uko > On 01 May 2015, at 12:07, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 01 May 2015, at 03:27, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> EstebanLM wrote >>> now we also have the concept of âPackage Manifestâ where you can put >>> comments and other stuff. >> >> Why does RPackage>>#packageManifest (which should just be named #manifest) >> return an instance of the manifest class, but all metadata is on the class >> side? > > probably a bug :) > > Esteban > >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Package-comments-tp4823188p4823415.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > >

May 1, 2015

Re: [Pharo-users] Fuel version

by Johannes Rasche Kreuzberg

Max, well the ConfigurationOfFuel in Pharo 3 does not know Fuel 1.9.4 and in Pharo 4 there is no ConfigurationOfFuel neither in the image (ConfigBrowser) nor on http://smalltalkhub.mc/Pharo/MetaRepoForPharo40/main what's up? do I oversee somthing relevant ? Johannes

May 1, 2015