- Pharo-users - lists.pharo.org

Re: [Pharo-users] How do you store and manage small programs?
by Andy Burnett Nov. 29, 2017

Nov. 29, 2017

Wow! What a great collection of answers. Thanks everyone, I learned a lot from that relatively simple question. I have installed QuickAccess - that's very cool. And, I have also tried the <script> pragma. Having the button is very nice. I will also try out Grafoscope. I have been playing with Mathematica Notebooks, and I think something similar within Pharo would be wonderful. Cheers Andy Yes. Plenty of solutions, from just open your Playground in a scripts folder, to QuickAccess, to objects, to embedding scripts into more complete data narratives. They serve different purposes, so explore them and see which ones serves better your taste and user case. Cheers, Offray On 26/11/17 07:07, Stephane Ducasse wrote: > Hi Andy > > As you saw there are plenty of solutions. > > Now what I learned is that it is often better in the long to have a > little object because suddenly > it opens your mind and you realise that you can teach him something more. > > So I often find myself realising that I created some class methods and > that it was stupid > better have a real little object because it can do more and in > particular for open new path > > So now I do not use scripts but plain little classes with nice little > printOn: methods and arguments > to get customized. > > Stef > > On Sat, Nov 25, 2017 at 6:34 PM, Andy Burnett > <andy.burnett(a)knowinnovation.com> wrote: >> I have just created a couple of small playground scripts that do some useful >> data wrangling. The chances are that I will reuse them from time to time, >> but with tweaks. Does version 6 Have some way to store them? I think I am >> after a sort of scripts catalogue. >

2 1

Using ZIP file system
by Juraj Kubelka Nov. 29, 2017

Nov. 29, 2017

Hi, Do I use the ZIP file system correctly? I do the following: -=-=-=- zipFile := FileLocator temp / 'file.zip'. zipFileSystem := (FileSystem zip: zipFile) open. (zipFileSystem root / 'dir1') createDirectory. (zipFileSystem root / 'dir1' / 'file.txt') writeStreamDo: [ :stream | stream << 'Hello World!' ]. zipFileSystem close. zipFile contents. -=-=-=- And zipFileSystem close produces an error. Thanks for any advice. Juraj

1 0

Strange behaviour when commit+push with Iceberg
by Julien Nov. 29, 2017

Nov. 29, 2017

Hello, Sometimes, when I do Â« commit and push Â» with Iceberg, I got this strange behaviour (see1st screenshot). I **must** interrupt the process to stop this madness. Then, I get even weirder things related to morphic (see the other screenshot). Then my image come back to a normal state and the commit + push have been performed. I hope this feedback can be helpful. I understand it may be too abstract description to fix the problem but I can not provide a formal way to reproduce this bug. Nevertheless, I thought I should report this behaviour which is not normal. Except this, I use Iceberg everyday for my projects now and yet it works well for me (I guess I have the right workflow that avoid problems). --- Julien Delplanque http://juliendelplanque.be/phd.html Doctorant Ã lâUniversitÃ© de Lille 1 Equipe Rmod, Inria NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40

2 1

UFFI C basic types passed-by-reference for output
by Ben Coman Nov. 29, 2017

Nov. 29, 2017

What is the recommended way for a C basic type to be passed-by-reference to function wanting to use it for output. For example 'width' & 'height' here in this library unction... int FPDF_GetPageSizeByIndex(FPDF_DOCUMENT document, int page_index, double* width, double* height); void mytestGetPageSizeByIndex(doc) { double width, height; FPDF_GetPageSizeByIndex(doc, 0, &width, &height); printf("width=%f, height=%f\n", width, height); } gives... width=200.000000, height=200.000000 In Pharo I'm trying... FFIOpaqueObject subclass: #FPDF_DOCUMENT FPDF_GetPageSizeByIndex__document: document page_index: page_index width: width height: height ^self ffiCall: #(int FPDF_GetPageSizeByIndex( FPDF_DOCUMENT *document, int page_index, FFIFloat64 * width, FFIFloat64 * height)) testGetPageSizeByIndex | document page_index width height result| PDFium FPDF_InitLibrary. document := PDFium FPDF_LoadDocument__file_path: helloPdf password: ''. width := 0.0. height := 0.0. page_index := 0. "Its zero based" result := PDFium FPDF_GetPageSizeByIndex__document: document page_index: 0 width: width height: height. PDFium FPDF_CloseDocument__document: document. PDFium FPDF_DestroyLibrary. self assert: document isNull not. "Document opened okay, and btw this works for a different pageCount test" self assert: result > 0. "Non-zero for success. 0 for error (document or page not found)" self halt. and at the halt the Inspector shows... result = 1 width = 0.0 height = 0.0 cheers -ben

2 6

PetitCompiler loading problem
by Julien Nov. 28, 2017

Nov. 28, 2017

Hello, Iâd like to try PetitCompiler to speed-up a parser I did. When trying to load it in a Pharo 6.1 image I have an error related to its configuration: Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitCompiler; load. (Smalltalk at: #ConfigurationOfPetitCompiler) perform: #'loadStable'. Â« Error : Name not found : Magritte-Tests-Pharo-Model Â» Can someone help me? I haven't tried in older images. Julien

2 4

Autoupdate of playground contents up to the last keystroke
by Offray Vladimir Luna CÃ¡rdenas Nov. 28, 2017

Nov. 28, 2017

Hi, Grafoscopio uses Doru's suggestion for auto-updating its contents, as published in http://ws.stfx.eu/ETEC2JH7363M, but if you test that code you will see that the contents showed in the inform message are one keystroke behind of the current playground content, as showed below, which creates usability issues (we need to add empty spaces and new lines to get the proper content of the Playground saved). There is any way to store/show the actual contents of the playground, instead of one keystroke behind. Thanks, Offray

2 2

reusing ZnClient session
by Peter UhnÃ¡k Nov. 28, 2017

Nov. 28, 2017

Hi, I have a scenario where I need to login to some web app and then reuse the session/cookies in further requests. The basic approach (as presented in Enterprise Pharo book) works just fine client := ZnClient new. client url: 'http://example.com/login'; formAt: 'username' put: 'john.doe(a)acme.com'; formAt: 'password' put: 'trustno1'; post. client get: 'http://example.com/my-file'. The problem is when I want to change the way response is retrieved. E.g. client accept: 'text/json'; contentReader: [ :entity | STON fromString: entity contents ]; get: 'http://example.com/some.json'. "uh-oh... it still uses STON contentReader" client get: 'http://example.com/homepage.html' Of course I could manually copy all the cookies, however I imagine there is a better approach. Maybe injecting session from one ZnClient instance to another? Thanks, Peter

2 2

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))
by Alistair Grant Nov. 27, 2017

Nov. 27, 2017

Hi Sean, Thanks for your feedback! (responses below) On 12 November 2017 at 18:11, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Alistair Grant wrote >> https://github.com/akgrant43/Pharo-Chrome > > Wow, that was a wild ride! Sorry about that. > Lessons learned along the way: > 1. On a Mac, to use the snazzy `chrome` terminal command referenced all over > the place in the docs, you must first `alias chrome="/Applications/Google\ > Chrome.app/Contents/MacOS/Google\ Chrome"` I'm an Ubuntu Linux user, however if you look at OSXChromePlatform class>>defaultExecutableLocation you can see that is where it should be looking for the exe, so the alias shouldn't really be necessary. Torsten wrote this, so maybe has more insight. > 2. Chrome must be started with certain flags: `chrome > --remote-debugging-port=9222 --disable-gpu` (not sure if the last flag is > needed, but `#get:` seemed to hang before using; reference > https://developers.google.com/web/updates/2017/04/headless-chrome) I've been using this without headless mode. I'll add a headless flag that also disables the gpu. > 3. Beacon has renamed InMemoryLogger to MemoryLogger > 4. I guess Beacon has renamed `#log` to `#emit` Sorry about that. I didn't realise that the Pharo-Chrome baseline is loading Beacon stable while my install script upgrades it to #development. #development is more recent, so I'll update the baseline. > 5. I had to comment out `chromeProcess sigterm.` because `chromeProcess` was > nil and also #sigterm seemed not to be defined anywhere in the image. I'm > not sure what the issue is there. chromeProcess is set in GoogleChrome>>openURL:. Can you give me a small example that demonstrates the problem? #sigterm is implemented by OSSUnixSubprocess, which is what I ultimately use to launch the Chrome process on Ubuntu. But... this will be broken on Mac at the moment because the current method of launching chrome doesn't keep track of the process, so doesn't support #sigterm. Do you know if OSSUnixSubprocess works on Mac? If it does, I can update the code (but not test it :-(). > Pull request issued for #3 & #4. Once I update the baseline this shouldn't be required. > Also, I'm not sure what platforms you > support, but you may want to tag the example methods with <gtExample> or > similar so that they are runnable from the browser and open an inspector if > there is an interesting return value. Good idea, I'll do this. I'm also making a few other changes: 1. Add an #extractTables method that searches through the page and returns an array of rows for each table it finds in the page (something that can easily be loaded in to DataFrame using #fromRows:, but I don't want to make Pharo-Chrome dependent on DataFrame at the moment). Most of the time I use Pharo-Chrome it is extracting data from tables. 2. I don't know of any reliable way to tell when a page has loaded since there can always be javascript that periodically updates the page. At the moment it waits until the page hasn't changed for a configurable amount of time. I'm planning to add a check for specific content to determine if the page is considered loaded. 3. Add some documentation to the readme :-) > ----- > Cheers, > Sean I'll let you know when I have a new version available (hopefully in the next few days). Thanks again, Alistair

7 32

Re: [Pharo-users] Removing instance variables doesn't recompile the methods
by abdelghani ALIDRA Nov. 27, 2017

Nov. 27, 2017

Hi Peter, Yes. More basically : 1) you compile a method with parameter anObject 2) you add an instance anObject 3) you try to modify/compile the method and you have a message error. Maybe there should be a kind of warning message Abdelghani -------------------------------------------- En date deÂ : Lun 27.11.17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> a Ã©critÂ : Objet: Re: [Pharo-users] Removing instance variables doesn't recompile the methods Ã: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Cc: "abdelghani ALIDRA" <alidrandco(a)yahoo.fr> Date: Lundi 27 novembre 2017, 10h21 As far as I know this has been a _feature_ for a very long time.Automatic recompiling methods is not the best idea, because: 1) you compile a method with temp var "hello" that uses inst var "world"2) you add a inst var "hello"3) you remove "world"4) trying to recompile the method will fail, because suddenly there's a clash between temp var "hello" and inst var "hello" Don't forget that the methods are compiled, not interpreted. So this behavior is expected. Peter On Mon, Nov 27, 2017 at 6:03 AM, Ben Coman <btc(a)openinworld.com> wrote: Thanks for reporting Abdelghani.Now it would be doubly useful if you could isolate which build introduced the problem.PharoLauncher can be used to help bisect working/non-working images. cheers -ben On 27 November 2017 at 04:08, abdelghani ALIDRA via Pharo-users <pharo-users(a)lists.pharo.org> wrote: ---------- Forwarded message ---------- From:Â abdelghani ALIDRA <alidrandco(a)yahoo.fr> To:Â "pharo-users(a)lists.pharo. org" <pharo-users(a)lists.pharo.org> Cc:Â Bcc:Â Date:Â Sun, 26 Nov 2017 20:08:29 +0000 (UTC) Subject:Â Removing instance variables doesn't recompile the methods Hi, In a fresh pharo 6 image, I add a class with an instance variable x and implement accessors. Then I write a test method for the accessors of x MyClassTest>>testReadWriteX Â Â Â self assert (MyClass new x: 0) x equals: 0 I run the test and obviously it is green BUT I remove the instance variable x. Obviously, the accessors are broken and the test should be red when I execute it again but it is not!!! I can even change the class again (to recompile it I thought) or even load the code in a new image and the tests are still green. I can also invoque the broken methods in a playground or in an inspector : MyClass new x: 0; increment; x then printIt. and astonishingly 1 is printed. The only way to detect the error is to recompile the method but this does not happen (maybe it should) when instance variables are modified or removed in the class (even when you use the refactoring tool!) I think this is annoying because one can no more really trust his tests. Cheers Abdelghani

1 0

Re: [Pharo-users] Removing instance variables doesn't recompile the methods
by abdelghani ALIDRA Nov. 27, 2017

Nov. 27, 2017

Hi Ben, I will try to see. I dont have my PC right now Abdelghani -------------------------------------------- En date deÂ : Lun 27.11.17, Ben Coman <btc(a)openinworld.com> a Ã©critÂ : Objet: Re: [Pharo-users] Removing instance variables doesn't recompile the methods Ã: "abdelghani ALIDRA" <alidrandco(a)yahoo.fr>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Date: Lundi 27 novembre 2017, 6h03 Thanks for reporting Abdelghani.Now it would be doubly useful if you could isolate which build introduced the problem.PharoLauncher can be used to help bisect working/non-working images. cheers -ben On 27 November 2017 at 04:08, abdelghani ALIDRA via Pharo-users <pharo-users(a)lists.pharo.org> wrote: ---------- Forwarded message ---------- From:Â abdelghani ALIDRA <alidrandco(a)yahoo.fr> To:Â "pharo-users(a)lists.pharo.org" <pharo-users(a)lists.pharo.org> Cc:Â Bcc:Â Date:Â Sun, 26 Nov 2017 20:08:29 +0000 (UTC) Subject:Â Removing instance variables doesn't recompile the methods Hi, In a fresh pharo 6 image, I add a class with an instance variable x and implement accessors. Then I write a test method for the accessors of x MyClassTest>>testReadWriteX Â Â Â self assert (MyClass new x: 0) x equals: 0 I run the test and obviously it is green BUT I remove the instance variable x. Obviously, the accessors are broken and the test should be red when I execute it again but it is not!!! I can even change the class again (to recompile it I thought) or even load the code in a new image and the tests are still green. I can also invoque the broken methods in a playground or in an inspector : MyClass new x: 0; increment; x then printIt. and astonishingly 1 is printed. The only way to detect the error is to recompile the method but this does not happen (maybe it should) when instance variables are modified or removed in the class (even when you use the refactoring tool!) I think this is annoying because one can no more really trust his tests. Cheers Abdelghani

1 0