December 2018 - Pharo-users

Re: [Pharo-users] good game plan for AoC2015 day 4

by Richard O'Keefe

This is the puzzle where you have to find the smallest integer such that '<some salt>' , (that integer) printString has an MD5 hash beginning with 5 hexadecimal zeros? Brute force is just fine. Calling libnettle's MD5 functions from a C program, it found the right answer in under 0.2 seconds on a cheap laptop. If using the MD5 class in Pharo doesn't take a reasonable time, you may find that (MD5 isPluginAvailable) is false. On my cheap laptop, the obvious code took 30 seconds to find the right answer, which surely means that the plugin is *not* available. But there is absolutely no point in looking for anything faster. So, (0 to: 1000000) findFirst: [:n | |digest| digest := MD5 hashMessage: 'YOUR SALT GOES HERE' , n printString. ... bytes begins with 00000 ...] Linear search. Compute string. Compute its MD5 hash. Check the result. The only time-consuming thing was browsing the MD5 class (and its superclass HashFunction) to figure out the interface. Now it *could* have turned out to be too slow to be useful, in which case another strategy would have been needed. But it didn't. (I started with a rather smaller bound to get an idea of how fast it was, and it was fast enough.) On Mon, 10 Dec 2018 at 00:30, Roelof Wobben <r.wobben(a)home.nl> wrote: > Helllo, > > a question about day4 of 2015 > is it right that I can only solve this bruteforece > so begin at for example 1 , encode it, check for 5 zeros if found then I > have found it otherwise increase the counter and do it again > https://adventofcode.com/2015/day/4 > > Regards, > > Roelof > >

Dec. 12, 2018

Re: [Pharo-users] Reify RBLiteralNode and RBBlockNode args/return with MetaLink?

by Marcus Denker

> On 28 Nov 2018, at 09:38, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >>> >>> >>> i) How do I reify the value of an RB(Valuel|Literal|LiteralValue)Node? RFValueReification does not work, and there is no reification for literal, value, or literal value nodes. > > This is now fixed. All subclasses of RBValueNode with the exception of Cascade now support #value. (Cascade: see below). > >>> ii) How do I reify arguments and results of blocks? I tried reify context for the block body #before and value for #after block "last", but I often run into the problem of no reification for literals. > > I added issue tracker entries: ... > https://pharo.fogbugz.com/f/cases/22703/Block-execution-arguments-reificati… <https://pharo.fogbugz.com/f/cases/22703/Block-execution-arguments-reificati…> > I added a first fix and simple tests for this, it is in the latest version. -> when putting a link on a block body, one can reify #arguments TODO: => clean up the situation block definition vs block body => test in real world situations (might not yet work for more complex cases, e.g. nested blocks) => support #value in after links. Marcus

Dec. 12, 2018

[ANN] Next Pharo Sprint: Dec 21

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Dec 21, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Pharo 7 issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come https://association.pharo.org/event-2973628

Dec. 12, 2018

Re: [Pharo-users] Submitting HTML Forms

by Sven Van Caekenberghe

Richard, You are mixing several aspects. I can only answer for Zinc itself, not Teapot. First start a local server ZnServer startDefaultOn: 1701. Then go to the example (handler) at http://localhost:1701/form-test-3 and try uploading a text file. If all goes well you will see its contents displayed. Check the code at ZnDefaultServerDelegate>>#formTest3: To do the same programmatically, client side, do ZnClient new url: 'http://localhost:1701/form-test-3'; addPart: (ZnMimePart fieldName: 'file' fileNamed: '/tmp/foo.txt'); post. In the response HTML that you get back, you will see the contents of your text file. Of course the field name must match what the handler expects. HTH, Sven > On 12 Dec 2018, at 05:13, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > > I'm having a lot of difficulty getting file uploading to work using Teapot/Zinc. The documentation is not entirely clear about how it's supposed to work, and the example provided doesn't quite work. I'm referring to section "4.6 Submitting HTML Forms" in "Enterprise Pharo â a Web Perspective." > > Here's my setup... > > I have a Teapot route like: > > GET: '/upload-handler' -> [ :req | self uploadHandler: req ]; > > where > > uploadHandler: req > ^ '<div> > <form method="POST" action="upload-handler" enctype="multipart/form-data"> > <input type="file" name="fileupload"> > <input type="submit" value="Upload!"> > </form> > </div>' > > I have a submission form like: > > GET: '/submission' -> [ :req | self submissionPage: req ]; > POST: '/submission' -> [ :req | self handleSubmission: req ]; > > where > > submissionPage: req > ^ '<div> > <form method="POST"> > <input type="file" name="fileupload" value=""> > <input type="submit" value="Submit"> > </form> > </div>' > > handleSubmission: req > ZnClient new > url: 'http://174.117.171.194/upload-handler'; > addPart: (ZnMimePart > fieldName: 'fileupload' fileNamed: 'S1-ABCD012345.st' ); > post. > > When I submit the submission form, I get "FileDoesNotExist: File @ /S1-ABCD012345.st". > > It doesn't matter what path I use to get to S1-ABCD012345.st. I tried "/Users/richardeng/Documents". I tried "/Documents". I tried "/". I don't know what path it's looking for. The file is there â there's no reason why it can't find it. > > I guess I'm just not understanding how this whole thing is supposed to work. Any ideas? > > Richard

Dec. 12, 2018

Re: [Pharo-users] any ihint how to do this

by Torsten Bergmann

>is there a way I can check if a word has 2 the same chars after each other Use #pairsCollect: 'hello' pairsCollect: [:a :b | a = b ] There is also a #pairsDo: 'hello' pairsCollect: [:a :b | Transcript show: a asString; show: b asString ] Have fun T. (aka astares)

Dec. 12, 2018

Re: [Pharo-users] [ANN] Pharo Newsletter December 2018

by Marcus Denker

> On 11 Dec 2018, at 14:08, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > Last we the Pharo Newsletter December 2018 was send. > > You can find the archived version now here: > > https://mailchi.mp/pharo/pharo-newsletter-december-2018 > I am looking for content for the January newsletter. e.g. if you know a library that has not yet been listed, or just one where some new version has been released. Or people could write âlargerâ articles (a paragraph or two) about their favourite things. Or maybe there are videos that would be nice to be added to the newsletter? Marcus

Dec. 12, 2018

Submitting HTML Forms

by Richard Kenneth Eng

I'm having a lot of difficulty getting file uploading to work using Teapot/Zinc. The documentation is not entirely clear about how it's supposed to work, and the example provided doesn't quite work. I'm referring to section "4.6 Submitting HTML Forms" in "Enterprise Pharo â a Web Perspective." Here's my setup... I have a Teapot route like: GET: '/upload-handler' -> [ :req | self uploadHandler: req ]; where uploadHandler: req ^ '<div> <form method="POST" action="upload-handler" enctype="multipart/form-data"> <input type="file" name="fileupload"> <input type="submit" value="Upload!"> </form> </div>' I have a submission form like: GET: '/submission' -> [ :req | self submissionPage: req ]; POST: '/submission' -> [ :req | self handleSubmission: req ]; where submissionPage: req ^ '<div> <form method="POST"> <input type="file" name="fileupload" value=""> <input type="submit" value="Submit"> </form> </div>' handleSubmission: req ZnClient new url: 'http://174.117.171.194/upload-handler'; addPart: (ZnMimePart fieldName: 'fileupload' fileNamed: 'S1-ABCD012345.st' ); post. When I submit the submission form, I get "FileDoesNotExist: File @ /S1-ABCD012345.st". It doesn't matter what path I use to get to S1-ABCD012345.st. I tried "/Users/richardeng/Documents". I tried "/Documents". I tried "/". I don't know what path it's looking for. The file is there â there's no reason why it can't find it. I guess I'm just not understanding how this whole thing is supposed to work. Any ideas? Richard

Dec. 12, 2018

Agile Artificial Intelligence book

by Alexandre Bergel

Dear Colleagues and Friends, The first 6 chapters of Agile Artificial Intelligence are now stable. Now is a good time for reviewing them. The chapters are available online from: https://agileartificialintelligence.github.io/ You can also see that the structure of the book has evolved. I believe that the part are stable. Maybe content of Part II and Part III can still evolve. You can contribute to the chapters by simply making a pull-request. People who do so, (i) will have their name listed on the book website, (ii) will have their name in the printed version of the book, and (iii) I will be very happy to invite you for a beer next time we meet. Thanks to all of you who have pushed the book and sent encouragements. The community deserves your effort. Kind regards, Alexandre

Dec. 12, 2018

Re: [Pharo-users] chooseExistingFileReference:extensions:path:preview returning wrong FileReference?

by Ben Coman

https://pharo.fogbugz.com On Wed, 12 Dec 2018 at 01:54, Arturo Zambrano <arturo.zambrano(a)gmail.com> wrote: > Should I report a bug? If so please send me the link to thw issue tracker > > On Tue, 11 Dec 2018, 13:05 Sven Van Caekenberghe, <sven(a)stfx.eu> wrote: > >> I confirm that this does indeed seem to be a problem, weird. >> >> > On 11 Dec 2018, at 16:53, Arturo Zambrano <arturo.zambrano(a)gmail.com> >> wrote: >> > >> > Hi All, >> > I'm replacing a deprecated call by this: >> > UIManager default chooseExistingFileReference:extensions:path:preview:. >> > >> > The returned fileRefence does not point the actual file selected by the >> user (if the file was chosen navigating to other directories than the >> default). >> > For example: >> > >> > UIManager default chooseExistingFileReference:'Title' >> extensions:#('pdf') path: './' preview: nil >> > >> > <image.png> >> > >> > Inspect the result: >> > <image.png> >> > >> > >> > >> > It seems to be a bug, or maybe there is any other way to call the >> dialog. >> > >> > Any pointer is welcome. >> > >> > TIA >> > >> > >> > >> >> >>

Dec. 11, 2018

Re: [Pharo-users] stfx.eu down

by Sven Van Caekenberghe

> On 10 Dec 2018, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > This evening I somehow broke my stfx.eu server while doing an ubuntu dist upgrade (an old AWS EC2 machine). > > This means several websites / web services hosted by that machine are down, most notably mc.stfx.eu (hosting several of my packages) and ws.stfx.eu (used for shared smalltalk workspaces). A couple of Zinc tests will also fail. I recovered parts of the functionality: ws.stfx.eu (shared smalltalk workspaces) and zn.stfx.eu are back, so that normal Zinc unit tests should pass everywhere. At least all this is now running on Ubuntu 18.04.1 LTS on Pharo 7 64-bit, as it should. Next up is http://mc.stfx.eu for my Monticello repository, but that might take more time. > For source code access, all my public repos exist both in an up to date form on GitHub (http://github.com/svenvc) as well in the original form in SmalltalkHub (http://smalltalkhub.com/#!/~SvenVanCaekenberghe) or SS3. > > The main problem there is that the distributed ConfigurationsOf and Catalog entries will still point to the original. This is not a problem with git's BaselineOf definitions. > > Although the machine will no longer boot, I managed to mount the original volume on another instance so I can still access the whole filesystem. This will make it possible to eventually recover most services. But this will take time as these things never happen when it is convenient. It will give me an opportunity to modernise the setup though, which is good. > > Sorry for the inconvenience. > > Sven > > >

Dec. 11, 2018