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

Re: [Pharo-users] HTTP file logging for Zinc

by Esteban A. Maringolo

Thank you Sven! How does it work with FileStreams when the requests come from different threads of the server? I mean, is FileStream thread safe? I guess that if I have multiple images I should have a file per image, otherwise I couldn't write to a single file. I will add the payload logging somehow. Maybe writing to an SQLite db. Thank you again. Esteban A. Maringolo 2015-07-01 12:01 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Esteban, > > > On 29 Jun 2015, at 21:40, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > > Hello everyone, > > > > I want to record everything that goes in or out from our REST API > servers, maybe including HTTP payload (JSON mostly). > > > > ZnLogEvent seems to have the basic building blocks for logging, but I > want to know if there is > > a package/project that already provides file logging, so I can not only > have the logs, but also if the file format is compatible with other http > logs I can run traditional web log tools on them, like Webalizer or AWStats. > > > > Thank you! > > > > Esteban A. Maringolo > > I committed the following: > > === > Name: Zinc-HTTP-SvenVanCaekenberghe.432 > Author: SvenVanCaekenberghe > Time: 1 July 2015, 4:50:46.339985 pm > UUID: 56da27df-1641-4b62-ba6d-34345f31a1af > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.431 > > Added ZnCommonLogFormat, an object that formats ZnServerTransactionEvent > log objects using the Apache Common Log Format (Combined) > === > > From the class comment: > > === > I am ZnCommonLogFormat, I can output ZnServerTransactionEvent objects > using Apache Common Log Format (CLF). > > https://en.wikipedia.org/wiki/Common_Log_Format > https://httpd.apache.org/docs/trunk/logs.html#common > > > === > > Which will give the following output: > > === > 127.0.0.1 - - [01/Jul/2015:16:35:36 +02:00] "GET /random HTTP/1.1" 200 64 " > http://localhost:1701/help" "Mozilla/5.0 (Macintosh; Intel Mac OS X > 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 > Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:35:37 +02:00] "GET /random HTTP/1.1" 200 64 " > http://localhost:1701/help" "Mozilla/5.0 (Macintosh; Intel Mac OS X > 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 > Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:36:20 +02:00] "GET / HTTP/1.1" 200 977 "-" > "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 > (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:36:21 +02:00] "GET /echo HTTP/1.1" 200 674 > "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 > (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:36:25 +02:00] "GET /echo?foo=1 HTTP/1.1" 200 > 680 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) > AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:36:53 +02:00] "GET /echo?foo=12 HTTP/1.1" > 200 681 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) > AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" > 127.0.0.1 - - [01/Jul/2015:16:39:13 +02:00] "GET /random HTTP/1.1" 200 64 > "-" "curl/7.37.1" > 127.0.0.1 - sven [01/Jul/2015:16:40:43 +02:00] "GET /random HTTP/1.1" 200 > 64 "-" "curl/7.37.1" > 127.0.0.1 - - [01/Jul/2015:16:42:18 +02:00] "GET /bytes/256 HTTP/1.1" 200 > 256 "-" "Zinc HTTP Components 1.0" > === > > This still needs battle testing and feedback. > > HTH, > > Sven > > >

July 1, 2015

Key language differences with VW2.5

by Laura Risani

Hi all, I'm dealing with some VW2.5 code i want to read/port/rewrite. Are there any key syntactical/semantical differences one should be aware of? Thank you!

July 1, 2015

Re: [Pharo-users] skipping whole class

by Camille

> On 01 Jul 2015, at 18:24, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Is it possible to skip whole class from testing? > I could do "self skip" for individual methods, but the problems arise even in setUp so I would like to stop the whole class from being tested. Is that possbile? Yes it is: put a âself skipâ in the setUp method :) Camille > > Thanks, > Peter

July 1, 2015

skipping whole class

by Peter UhnÃ¡k

Is it possible to skip whole class from testing? I could do "self skip" for individual methods, but the problems arise even in setUp so I would like to stop the whole class from being tested. Is that possbile? Thanks, Peter

July 1, 2015

Seeking help to build an accordion widget for GUI of sQuick

by Jigyasa Grover

Hello All :) I am a newbie in Pharo and have started to build my first application i.e. an offline text search application namely searchQuick. You all are welcome to fork the code (https://github.com/jig08/sQuick_new) , try the infancy application and send in suggestions. Currently, I have built the basic structure of the application using Morphs and have a lot to cover on the GUI part. sQ basically returns the list of file titles from the pre-loaded text files present in the resource folder when a string is searched for. I plan to build an accordion widget (https://jqueryui.com/accordion/) or something similiar to view the results. I seek help on the implementation of this part. Looking forward to a positive response. Regards Jigyasa -- View this message in context: http://forum.world.st/Seeking-help-to-build-an-accordion-widget-for-GUI-of-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 1, 2015

loading with gofer without network

by Christophe Demarey

Hi, I'm trying to load a package (mcz) from the package cache with Gofer. |gofer| gofer := Gofer new repository: MCCacheRepository uniqueInstance; repository: (MCSmalltalkhubRepository owner: 'Seaside' project: 'Grease11'); version: 'Grease-Core-JohanBrichau.94'; disableRepositoryErrors; load As you see, I gave 2 repositories (the first is local, the second one is remote) to Gofer. If you try to execute this code without the network, it will failed! It shouldn't because the mcz is in the package cache. I think it is a bad behavior of Gofer. It does not have to resolve references for ALL the repositories because, at the end, you only use one. I want to change this behavior to only get the first resolved reference (no need to iterate more). If not acceptable, I could only ignore repositories not reachable (disableRepositoryErrors does not work for this use case). Is it ok to change it? Christophe

July 1, 2015

Re: [Pharo-users] HTTP file logging for Zinc

by Sven Van Caekenberghe

Esteban, > On 29 Jun 2015, at 21:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Hello everyone, > > I want to record everything that goes in or out from our REST API servers, maybe including HTTP payload (JSON mostly). > > ZnLogEvent seems to have the basic building blocks for logging, but I want to know if there is > a package/project that already provides file logging, so I can not only have the logs, but also if the file format is compatible with other http logs I can run traditional web log tools on them, like Webalizer or AWStats. > > Thank you! > > Esteban A. Maringolo I committed the following: === Name: Zinc-HTTP-SvenVanCaekenberghe.432 Author: SvenVanCaekenberghe Time: 1 July 2015, 4:50:46.339985 pm UUID: 56da27df-1641-4b62-ba6d-34345f31a1af Ancestors: Zinc-HTTP-SvenVanCaekenberghe.431 Added ZnCommonLogFormat, an object that formats ZnServerTransactionEvent log objects using the Apache Common Log Format (Combined) === >From the class comment: === I am ZnCommonLogFormat, I can output ZnServerTransactionEvent objects using Apache Common Log Format (CLF). https://en.wikipedia.org/wiki/Common_Log_Format https://httpd.apache.org/docs/trunk/logs.html#common | formatter | formatter := ZnCommonLogFormat new. ZnLogEvent announcer when: ZnServerTransactionEvent do: [ :event | formatter format: event on: Transcript. Transcript cr; endEntry ]. === Which will give the following output: === 127.0.0.1 - - [01/Jul/2015:16:35:36 +02:00] "GET /random HTTP/1.1" 200 64 "http://localhost:1701/help" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" 127.0.0.1 - - [01/Jul/2015:16:35:37 +02:00] "GET /random HTTP/1.1" 200 64 "http://localhost:1701/help" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" 127.0.0.1 - - [01/Jul/2015:16:36:20 +02:00] "GET / HTTP/1.1" 200 977 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" 127.0.0.1 - - [01/Jul/2015:16:36:21 +02:00] "GET /echo HTTP/1.1" 200 674 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" 127.0.0.1 - - [01/Jul/2015:16:36:25 +02:00] "GET /echo?foo=1 HTTP/1.1" 200 680 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" 127.0.0.1 - - [01/Jul/2015:16:36:53 +02:00] "GET /echo?foo=12 HTTP/1.1" 200 681 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12" 127.0.0.1 - - [01/Jul/2015:16:39:13 +02:00] "GET /random HTTP/1.1" 200 64 "-" "curl/7.37.1" 127.0.0.1 - sven [01/Jul/2015:16:40:43 +02:00] "GET /random HTTP/1.1" 200 64 "-" "curl/7.37.1" 127.0.0.1 - - [01/Jul/2015:16:42:18 +02:00] "GET /bytes/256 HTTP/1.1" 200 256 "-" "Zinc HTTP Components 1.0" === This still needs battle testing and feedback. HTH, Sven

July 1, 2015

Re: [Pharo-users] stream not working with MemoryFileSystemFile

by Christophe Demarey

Le 1 juil. 2015 Ã 14:42, Torsten Bergmann a Ã©crit : > Christophe Demarey >> I tried to create an in-memory file as following: >> (MemoryFileSystemFile named: 'Foo') >> writeStreamDo: [ :stream | stream nextPutAll: 'bar' ] >> >> Then I get an improper store into ByteArray. It looks like Character cannot be store in a byte array. >> I do not know if the bug is on the memory file system part or other. >> Any idea? > > Why do you use MemoryFileSystemFile directly. Usually the FileSystem is > the starting point. And there it works: > > |fs file| > fs := FileSystem memory. > file := fs / 'test'. > file writeStreamDo: [ :stream | stream nextPutAll: 'bar' ]. > fs inspect > > The nice thing is that you can now browse the file system and file contents > with the new GT Inspector. oh, perfect. Looks like I was not using the good api. Thanks, Christophe

July 1, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by H. Hirzel

Joachim, which results do you get on VA Smalltalk for the tests? Do they all pass? --Hannes On 7/1/15, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > I am not complaining. It just makes porting harder. > > What made the thing especially strange was that I only had that problem > with uploaded files because the Browser removes the trailing CrLf (or > better, doesn't add another one in the multipart form data). So reading > from a file all works like a charm, but not when you process the same, > uploaded file on the server side... > > Joachim > > Am 01.07.15 um 15:12 schrieb Sven Van Caekenberghe: >> Yes, on Pharo, #next (and #peek or #peekFor:) all return nil when #atEnd. >> >> It is the way it is (I am personally for stricter semantics), but that >> fact is certainly used in code all allround the place. >> >>> On 01 Jul 2015, at 15:06, jtuchel(a)objektfabrik.de wrote: >>> >>> Hi Sven, >>> >>> I didn't test on Pharo. But I remember seeing differences in the way >>> Pharo and VAST react to reads beyond the end of a Stream. >>> Not sure, but this could have been in NeoCSV context two or three years >>> ago. >>> >>> So it is very likely I was bitten by platform differences. >>> >>> Thanks for answering. >>> >>> Joachim >>> >>> Am 01.07.15 um 14:05 schrieb Sven Van Caekenberghe: >>>> Hi Joachim, >>>> >>>> First, thanks for the feedback. >>>> >>>> Second, since you are on a different platform, that might be a factor. >>>> >>>> Did you test your problem on Pharo itself ? >>>> >>>> Because there are already unit tests specifically for the case you >>>> describe: >>>> >>>> #testEmptyLastFieldUnquoted >>>> #testEmptyLastFieldQuoted >>>> >>>> These obviously pass for Pharo, do they pass for you ? >>>> >>>> Maybe your problem case is slightly different though ? >>>> >>>> Sven >>>> >>>>> On 01 Jul 2015, at 13:40, jtuchel(a)objektfabrik.de wrote: >>>>> >>>>> Hi, >>>>> >>>>> I've tried porting SvenVanCaekenberghe.20 and see the same problems in >>>>> this version. IN addition to the fix already mentioned, I also had to >>>>> change readSeparator: >>>>> >>>>> readSeparator >>>>> >>>>> ^self atEnd ifFalse: [self peekFor: separator] >>>>> >>>>> As far as I can tell by now, this fixes the problem at hand. Any ideas >>>>> if this is a safe fix? >>>>> >>>>> Joachim >>>>> >>>>> >>>>> Am 01.07.15 um 12:35 schrieb jtuchel(a)objektfabrik.de: >>>>>> Hi there, >>>>>> >>>>>> I am on VA Smalltalk and therefor using an older version of NeoCSV >>>>>> (SvenVanCaekenberghe.14). I found a bug in this old version that is >>>>>> somewhat special. >>>>>> >>>>>> It seems NeoCSV cannot handle the situation where the very last field >>>>>> is just empty AND if there is no trailing CRLF at the end of the file. >>>>>> Somethinng like this: >>>>>> >>>>>> SecondLastColumnValue;;<EOF> >>>>>> >>>>>> In that case, readField fails because it tries to do a readQuotedField >>>>>> or readUnquotedField, both of which try to read beyond EOF. >>>>>> >>>>>> So I changed readField to this: >>>>>> >>>>>> readField >>>>>> >>>>>> ^self atEnd "In case the very last field of a file is empty, like >>>>>> '45;56;;'" >>>>>> ifTrue: [''] >>>>>> ifFalse: [self peekQuote ifTrue: [self readQuotedField] >>>>>> ifFalse: [self readUnquotedField]] >>>>>> >>>>>> and all seems fine so far. >>>>>> >>>>>> Side note: My original file has a trailing CrLf but if I upload it via >>>>>> a browser to a Seaside Server, the Browser cuts off the trailing CrLf >>>>>> (I can see this in the Browser's Network debugging tools - both in IE >>>>>> and FF) - so it seems NeoCSV has to be ready for this situation. >>>>>> >>>>>> Joachim >>>>>> >>>>>> >>>>> -- >>>>> ----------------------------------------------------------------------- >>>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>>> Fliederweg 1 http://www.objektfabrik.de >>>>> D-71640 Ludwigsburg >>>>> http://joachimtuchel.wordpress.com >>>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>>>> >>>>> >>>> >>> >>> -- >>> ----------------------------------------------------------------------- >>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>> Fliederweg 1 http://www.objektfabrik.de >>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>> >>> >> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

July 1, 2015

Re: [Pharo-users] OpenCL problems since we switch to OS X 10.10.3

by Serge Stinckwich

I switch to 10.10.4 and still the same problem when I launch a simple demo. Process: Pharo [2003] Path: /Applications/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: Pharo 0.2.7-2015.04.20 (21.0) Code Type: X86 (Native) Parent Process: ??? [1] Responsible: Pharo [2003] User ID: 502 Date/Time: 2015-07-01 15:27:09.106 +0200 OS Version: Mac OS X 10.10.4 (14E46) Report Version: 11 Anonymous UUID: 53101D99-4009-6151-7D46-D4F943A588CF Sleep/Wake UUID: 9C69E3C7-C31D-4D2C-ADF8-CBCDC232EAE3 Time Awake Since Boot: 8500 seconds Time Since Wake: 3000 seconds Crashed Thread: 0 Dispatch queue: opencl_runtime Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 VM Regions Near 0x20: --> __TEXT 0000000000001000-00000000000a6000 [ 660K] r-x/rwx SM=COW /Applications/Pharo.app/Contents/MacOS/Pharo Application Specific Information: abort() called Thread 0 Crashed:: Dispatch queue: opencl_runtime 0 libsystem_kernel.dylib 0x9b27869a __pthread_kill + 10 1 libsystem_pthread.dylib 0x9b3fef19 pthread_kill + 101 2 libsystem_c.dylib 0x91d2feee abort + 156 3 org.pharo.Pharo 0x0004c2bf sigsegv + 175 4 libsystem_platform.dylib 0x9a1c803b _sigtramp + 43 5 ??? 0xffffffff 0 + 4294967295 6 org.pharo.Pharo 0x0004c210 reportStackState + 496 7 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x4045d791 CHAL_INTEL::COCLGen7CommandTransport::AddSurfaceStateTokensForCopy(CHAL_INTEL::tagCHALCommandPacket*, bool, bool) + 225 8 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x4045c50f CHAL_INTEL::COCLGen7CommandTransport::BuildGen7CommandBuffer(CHAL_INTEL::tagCHALCommandPacket*) + 277 9 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x40456357 CHAL_INTEL::ChalContext::SetupFixedFunctionKernelExecute(CHAL_INTEL::tagCHALCommandPacket*, unsigned long*) + 725 10 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x40456df8 CHAL_INTEL::ChalContext::ChalExecuteCopyBufferData(GLDBufferImageRegionRec*, GLDBufferRec*, GLDBufferImageRegionRec*, GLDBufferRec*, GLDFenceRec*) + 1388 11 com.apple.driver.AppleIntelHD4000GraphicsGLDriver 0x40450839 gldCopyBufferDataWithQueue + 315 12 com.apple.opencl 0x9bf1d69d 0x9bf1b000 + 9885 13 com.apple.opencl 0x9bf3ccca 0x9bf1b000 + 138442 14 com.apple.opencl 0x9bf40451 0x9bf1b000 + 152657 15 libdispatch.dylib 0x9b237130 _dispatch_client_callout + 50 16 libdispatch.dylib 0x9b238570 _dispatch_barrier_sync_f_invoke + 55 17 libdispatch.dylib 0x9b238537 dispatch_barrier_sync_f + 105 18 com.apple.opencl 0x9bf402c0 0x9bf1b000 + 152256 19 com.apple.opencl 0x9bf3bcd0 0x9bf1b000 + 134352 20 com.apple.opencl 0x9bf30c0f clEnqueueReadBuffer + 839 21 ??? 0x22b81b21 0 + 582490913 22 org.pharo.Pharo 0x0009727b primitiveNativeCall + 107 On Wed, May 20, 2015 at 5:05 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Hi Ronie, > > since we switch here from OS X 10.10.2 to 10.10.3, your OpenCL > framework doesn't not work anymore ... We crash Pharo everytime we try > to use GPU. > > This is an except of the crash log: > > Process: Pharo [21039] > Path: /Applications/Pharo.app/Contents/MacOS/Pharo > Identifier: org.pharo.Pharo > Version: Pharo 0.2.7-2015.04.20 (21.0) > Code Type: X86 (Native) > Parent Process: ??? [1] > Responsible: Pharo [21039] > User ID: 502 > > Date/Time: 2015-05-20 16:50:33.740 +0200 > OS Version: Mac OS X 10.10.3 (14D136) > Report Version: 11 > Anonymous UUID: 53101D99-4009-6151-7D46-D4F943A588CF > > Sleep/Wake UUID: D65CFFA9-9DD4-490B-99A5-D5A3F37C8649 > > Time Awake Since Boot: 240000 seconds > Time Since Wake: 19000 seconds > > Crashed Thread: 0 Dispatch queue: opencl_runtime > > Exception Type: EXC_BAD_ACCESS (SIGABRT) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 > > What can we do ? Apparently this is difficult to downgrade back to 10.10.2 > > Regards > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 1, 2015