January 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Couple grafoscopio notes

by Offray Vladimir Luna CÃ¡rdenas

Hi Peter, :-) On 19/01/17 11:49, Peter Uhnak wrote: > Hi, > > I've started playing around with grafoscopio, I am happy that I can finally organize all those little scripts and not lose them all the time. :) Thanks for using Grafoscopio. It started to explore moldability by bridging documentation and scripting with live coding and objects. Pharo and the communities around it have been really empowering for such exploration, so I'm glad you find it useful. > > However there are couple of issues and notes I've ran into (don't worry about fixing them in any timely fashion, it is not blocking me) > > 1. For saving `UITheme builder` is used, but the correct approach is via `UIManager default` > * this has obvious impact if the UIManager is different (UIManager has reference to UITheme, but not the other way around) > > To see all the calls, you can do this (or find the uses manually) > > calls := UITheme allCallsOn select: [ :each | each package name = #Grafoscopio ]. > SystemNavigation default browseMessageList: calls name: 'Users of class UITheme' autoSelect: 'UITheme builder'. > > 2. Typo "Add nodo" -> "Add node" > > 3. "Move up|down node" -> "Move node up|down" (to be consistend with the rest of the naming) Items 1 to 3 have been fixed. Please update to Grafoscopio-OffrayLuna.250 or later. > > 4. During installation (from Catalog) a 'Grafoscopio' folder is created in documents and documentation is downloaded > > This is a big no. Please don't do this. > Not only it violates the isolation of images, but it actually breaks the installation itself when you install Grafoscopio in two different images. > > If you have to download the docs and you cannot just store them inside the image (which would be logical choice for read-only), then please use the image's directory by default, and only in e.g. development mode use some other location. This was for historical reasons. At the beginning documentation was installed on the same image directory, but, as a developer, I need a fixed place to refer to the documentation from different images and also, in the Data Week workshops, participants need such fixed place to share scripts more easily. Now all documentation is located in the same image directory, so we don't violate images isolation, but the new menu item 'Update > Documents place' is available, if users need some fixed shared location to work on shared notebooks (this will be improved, but works for now). In the future I plan to make the notebook tree available from the playgrounds embedded in it, so you can write stuff like: 'thisNode children computeAll; exportAsHTML", to bring self-referential programable notebooks to Pharo and data storytelling :-), but that would be theme for its own mail thread. > > 5. Node-related bugs > > Imho this is somehow related to improper use and updates of tree. I remember I had similar issues some time ago, so maybe I can take a look at this in couple of weeks. > > These bugs sometimes autoresolve themselves (so sometimes it is usable and sometimes not) > > * 1. Launch > new notebook > * 2. Add node > error > > * 1. Launch > new notebook > * 2. Select Node 1 > * 3. Add node > * 4. Select newNode > * 5. rename node to something else > * 6. Click on previous "Node 1" > error Yes. I don't understand pretty well the Spec GUI, its events, and its relation with GT-Tools. I would like to have shorcuts for saving the notebook, move nodes in the tree, creation, selection and edition, so I will be interested in your recommendations in a couple of weeks. Let me know, also, if you need any particular permission in the repository. > > To summarize: > > Most are just minor things or annoyances, but #4 is breaking --- as I have to remember to delete the folder every time I want to download Grafoscopio in new image. (If it works for you, then maybe it's platform related (I tested this on Windows 10); in either case, the data related to the image should stay with the image (either in the image, or in the image's folder), and not somewhere in the system). > > Thanks! > > Peter > Thanks, Offray

Jan. 21, 2017

Google summer of code

by Alexandre Bergel

Hi everyone- Google Summer of Code 2017 has officially begun! Organization applications open today, Thursday January 19 and are open through Thursday, February 9th. Please see our program site, <http://g.co/gsoc> official timeline <https://developers.google.com/open-source/gsoc/timeline> and FAQ <https://developers.google.com/open-source/gsoc/faq> for more details. What makes a good organization application? Take a look at our manuals <https://developers.google.com/open-source/gsoc/resources/manual> for tips and best practices. We look forward to seeing each of your applications and kicking off another great year of GSoC. If you have any questions, donât hesitate to reach out to gsoc-support(a)google.com <mailto:gsoc-support@google.com>. Weâre here to help! Google Open Source Programs Office -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2017

Re: [Pharo-users] Tools for easy subtext extraction from text

by Henrik Nergaard

You can use #match and #upTo: on a ReadStream for easy extraction ---------------------------------------- | text digits| text := ' Temperature 0 37C (98F) [0x25] (TMPIN0)' digits:= text readStream match: '[0x' ; upTo: $]. ( '16r' , digits ) asNumber "37" ---------------------------------------- Best regards, Henrik -----Opprinnelig melding----- Fra: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] PÃ¥ vegne av Peter Uhnak Sendt: 20 January 2017 16:16 Til: pharo-users(a)lists.pharo.org Emne: [Pharo-users] Tools for easy subtext extraction from text Hi, what are the tools available from easier text extraction? The input is unstructured text, but I want to extract portion from it. I am not looking for an engineered approach (writing a parser or something), but something that can be done quickly by hand (i.e. interactively). For example I have string str = ' Temperature 0 37C (98F) [0x25] (TMPIN0)' Now I want to extract '0x25' from it and convert it into integer In Ruby it is dead simple: str[/\[(.*)\]/,1].hex # "=> 37" , or .to_i(16) In Pharo I have to break my fingers first: rx := '.*\[0x(.*)\].*' asRegex. rx matches: str. Integer readFrom: (rx subexpression: 2) base: 16 "=>37". * I have to know that to get subexpression I have to match first to manipulate the internal state * I have to store the matcher to access the subexpression * I need to explicitly use some global variable Integer as a conversion utility to convert hex to dec * I have to manually remove the 0x, even though it is a very common way of expressing hex numbers So the question is: do we have a better way to do these things? And as I've mentioned - the use case is interactive coding where you often throw the code away when you are done; so dead easy to write and use. Thanks, Peter

Jan. 20, 2017

Re: [Pharo-users] [Seaside] Bad Request ZnEntityTooLarge

by Bernhard Pieber

Hi Johan, Thank you for your detailed answer. See below. > Am 20.01.2017 um 10:12 schrieb Johan Brichau <johan(a)inceptive.be>: > > imho, itâs better practice to detect too large file upload in your app on the client side, i.e. before your user has been uploading xxx MB. For that, you can check out various client-side programs like jQuery-FileUpload (https://blueimp.github.io/jQuery-File-Upload/) Thanks for the pointer. I will look into adding somthing like this on the client side. Someone mentioned using Dropzone.js from Seaside. I had searched stackoverflow for limiting upload file size and found some helpful tips: http://stackoverflow.com/questions/11514166/check-file-size-before-upload However, I also found warnings like these: âKeep in mind that even if it's now possible to validate on the client, you should still validate it on the server, though. All client side validations can be bypassed.â âOf course, this â¦ can be tampered with so always use server side validation.â This is why I wanted to find a user-friendly way to prevent this from my server code. Are you saying, this is not necessary in your opinion? > You also might want to check out this: http://jbrichau.github.io/blog/large-file-upload-in-seaside > And Nickâs original post has come back online since I wrote mine too: http://nickager.com/blog/2011/07/01/File-upload-using-Nginx-and-Seaside Yes, I had seen this. In my case I have to use Apache, which is configured by someone else. Do you know if anyone has done this for Apache? > The adaptor framework was built to minimize dependencies between Seaside and the http server. To make Seaside aware about an error occurring inside the http server, and allow to produce a response to it, a specialized extension of the adaptor is necessary. I think you _can_ make a nice looking page using Seaside when you tell Zinc that it should respond to the error using Seaside. Both Zinc and Seaside are frameworks and you can customize them by specializing appropriate methods. If you create your own ZnSeasideServerAdaptorDelegate and override #handleRequest: to catch the error, you can dispatch to the Seaside framework to render a nice looking page. Thanks for the tip. I tried this. However, I cannot catch ZnEntityTooLarge in handleRequest, because Zinc handles it before. Maybe Kom would work. > There are several ways to dispatch back to Seaside. The easiest way would be to generate a generic page using the WABuilder: > > WAHtmlCanvas builder render: [ :html | html text: âOopsâ¦ entity too large!â ] > > However, that does not dispatch back to your running app and you probably expect to be able to specify some other callback in your Seaside code that would execute on that error? Well, ideally I could catch that exception, update some domain object, and refresh the page where the upload originated from. > This would make your app dependent on Zinc though (and the Seaside framework would need be extended to handle that additional dependency on adaptors). I am not sure I understand. Wouldnât it be possible to have a common API between adaptor and server which allows for streaming uploads? Being able to write something like this sure would be nice: html fileUpload streaming: true; callback: [:stream | â¦ ]. > Not sure if all that work makes sense when this kind of upload error is preferably handled differently. Good point. > cheers > Johan > > >> On 20 Jan 2017, at 07:04, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> Thank you for your answer, Sven. >> >> Thatâs a bummer. If I understand you correctly, currently there is no hook in Seaside to catch lower level server exceptions (like ZnEntityTooLarge) to show a nice looking error page, e.g. âYou are trying to upload a file thatâs too large. Donât do that!â Really? :-/ >> >> Cheers, >> Bernhard >> >>> Am 19.01.2017 um 14:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> Hi Bernard, >>> >>> Your analysis is correct. >>> >>> Most Seaside adaptors, including ZnZincServerAdaptor, are implemented so that the incoming (Zn) request is read from the wire, then converted to Seaside WA* objects, processed, the result converted from WA* objects to an outgoing (Zn) response and put on the wire. >>> >>> Zn has some built-in resource protection measures, including a limit on how large entities (bodies) can be. The error of crossing such a limit is raised in the very first step, outside the scope of your Seaside handling code. >>> >>> At first sight, I would not immediately know how this can be solved. >>> >>> Note that in order to know how much is coming in, you have to read it, but you have to stop in time. Note also that the content-length header could be absent or wrong (a malicious request). >>> >>> I can't remember where we currently stand on a streaming Zn Seaside adaptor, there were some experiments in the past IIRC. That could be a solution, because then the entity/body is not read until further down the line, if we can get it to work. The current one only seems to do streaming for responses. >>> >>> Sven >>> >>>> On 19 Jan 2017, at 13:32, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>>> >>>> I have a Seaside application which includes a file upload feature. >>>> >>>> renderContentOn: html >>>> â¦ >>>> html fileUpload >>>> callback: [ :file | self receiveFile: file ]. >>>> html submitButton: 'Uploadâ ] >>>> â¦ >>>> >>>> In receiveFile: I just save the uploaded file on the file system. >>>> >>>> When I upload a file larger than 16 MB an error page is shown with the error message: >>>> Bad Request ZnEntityTooLarge >>>> >>>> I found that by using ZnConstants>>maximumEntitySize: I can increase this limit. However, I want to catch this in the image and show an error message to the user. >>>> >>>> I tried wrapping receiveFile: and renderContentOn: with an on:do: exception handler for ZnEntityTooLarge. However, neither works. It seems that the error happens before renderContentOn: is even called. I searched the mailing lists but did not come up with an answer. >>>> >>>> How can I achieve this in Seaside? Any help would be much appreciated. >>>> >>>> Cheers, >>>> Bernhard

Jan. 20, 2017

Re: [Pharo-users] is PetitParser eager by default?

by Tudor Girba

Hi, When you have questions like these, you can also use the built-in debugging facilities. For example, in your case, you can see that the #any parser consumed everything like this: Cheers, Doru > On Jan 20, 2017, at 4:38 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 20.01.2017 um 15:24 schrieb Peter Uhnak <i.uhnak(a)gmail.com>: >> >> Is PetitParser eager by default? >> >> I've used PetitParser countless times so I am really baffled why this doesn't work >> >> str := 'a0b'. >> #any asParser star, #digit asParser, #any asParser star parse: str. >> >> -> PPFailure (input expected at: 3) >> > > PetitParser is not greedy per default. But back tracking only works if a parser fails. Using , creates a sequence of combined parsers. If one fails the whole sequence fails. As a star parser always succeeds it would be huge luck if your rule would succeed. The probability that the parser consumes exactly one character is not high. Maybe negating the first sequence part is what you want > > Norbert > > -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

Jan. 20, 2017

Re: [Pharo-users] is PetitParser eager by default?

by Norbert Hartl

> Am 20.01.2017 um 15:24 schrieb Peter Uhnak <i.uhnak(a)gmail.com>: > > Is PetitParser eager by default? > > I've used PetitParser countless times so I am really baffled why this doesn't work > > str := 'a0b'. > #any asParser star, #digit asParser, #any asParser star parse: str. > > -> PPFailure (input expected at: 3) > PetitParser is not greedy per default. But back tracking only works if a parser fails. Using , creates a sequence of combined parsers. If one fails the whole sequence fails. As a star parser always succeeds it would be huge luck if your rule would succeed. The probability that the parser consumes exactly one character is not high. Maybe negating the first sequence part is what you want Norbert

Jan. 20, 2017

Re: [Pharo-users] is PetitParser eager by default?

by Guillaume Larcheveque

Yes, the #any asParser star consume all your stream. for your example you can do: str := 'a0b'. #digit asParser negate star, #digit asParser, #any asParser star parse: str. 2017-01-20 15:24 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Is PetitParser eager by default? > > I've used PetitParser countless times so I am really baffled why this > doesn't work > > str := 'a0b'. > #any asParser star, #digit asParser, #any asParser star parse: str. > > -> PPFailure (input expected at: 3) > > > Thanks, > Peter > > -- *Guillaume Larcheveque*

Jan. 20, 2017

Re: [Pharo-users] is PetitParser eager by default?

by Peter Uhnak

On Fri, Jan 20, 2017 at 04:57:51PM +0100, Tudor Girba wrote: > Hi, > > When you have questions like these, you can also use the built-in debugging facilities. For example, in your case, you can see that the #any parser consumed everything like this: Ah, thanks. I was looking for this in the debugger (because I remember there was some extension related to PetitParser) and completely missed it in the playground. > >> Am 20.01.2017 um 15:24 schrieb Peter Uhnak <i.uhnak(a)gmail.com>: > >> > >> Is PetitParser eager by default? > >> > >> I've used PetitParser countless times so I am really baffled why this doesn't work > >> > >> str := 'a0b'. > >> #any asParser star, #digit asParser, #any asParser star parse: str. > >> > >> -> PPFailure (input expected at: 3) > >> > > > > PetitParser is not greedy per default. But back tracking only works if a parser fails. Using , creates a sequence of combined parsers. If one fails the whole sequence fails. As a star parser always succeeds it would be huge luck if your rule would succeed. The probability that the parser consumes exactly one character is not high. Maybe negating the first sequence part is what you want This is not just about one character. s := 'hello 123 world'. #any asParser star , #digit asParser plus , #any asParser star parse: s. But from your explanation my understanding is that this is actually not possible with #any. Basically I was looking for the PetitParser equivalent of .*?\d+.* regex (note that even in greedy form the regex wouldn't fail because it would leave the last digit for \d) Peter

Jan. 20, 2017

Tools for easy subtext extraction from text

by Peter Uhnak

Hi, what are the tools available from easier text extraction? The input is unstructured text, but I want to extract portion from it. I am not looking for an engineered approach (writing a parser or something), but something that can be done quickly by hand (i.e. interactively). For example I have string str = ' Temperature 0 37C (98F) [0x25] (TMPIN0)' Now I want to extract '0x25' from it and convert it into integer In Ruby it is dead simple: str[/\[(.*)\]/,1].hex # "=> 37" , or .to_i(16) In Pharo I have to break my fingers first: rx := '.*\[0x(.*)\].*' asRegex. rx matches: str. Integer readFrom: (rx subexpression: 2) base: 16 "=>37". * I have to know that to get subexpression I have to match first to manipulate the internal state * I have to store the matcher to access the subexpression * I need to explicitly use some global variable Integer as a conversion utility to convert hex to dec * I have to manually remove the 0x, even though it is a very common way of expressing hex numbers So the question is: do we have a better way to do these things? And as I've mentioned - the use case is interactive coding where you often throw the code away when you are done; so dead easy to write and use. Thanks, Peter

Jan. 20, 2017

is PetitParser eager by default?

by Peter Uhnak

Is PetitParser eager by default? I've used PetitParser countless times so I am really baffled why this doesn't work str := 'a0b'. #any asParser star, #digit asParser, #any asParser star parse: str. -> PPFailure (input expected at: 3) Thanks, Peter

Jan. 20, 2017