December 2018 - Pharo-users

Re: [Pharo-users] Submitting HTML Forms

by Sven Van Caekenberghe

> On 12 Dec 2018, at 17:26, horrido <horrido.hobbies(a)gmail.com> wrote: > > Okay, I managed to hack together a solution from the example. It's not pretty > but it seems to work. I needed to remain within the Teapot framework. > > However, I have a question regarding the ZnEntityTooLarge exception. How can > I capture it and resume execution? The exception seems to occur before my > POST handler is called. The default is 16Mb. Nowadays you can set it using #maximumEntitySize: on ZnServer (and on ZnClient). There is also a dynamic/process-local variable ZnMaximumEntitySize. > Sven Van Caekenberghe-2 wrote >> 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@ > >> > 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 > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 12, 2018

Re: [Pharo-users] Submitting HTML Forms

by horrido

Okay, I managed to hack together a solution from the example. It's not pretty but it seems to work. I needed to remain within the Teapot framework. However, I have a question regarding the ZnEntityTooLarge exception. How can I capture it and resume execution? The exception seems to occur before my POST handler is called. Sven Van Caekenberghe-2 wrote > 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@ > > 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 -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 12, 2018

[ANN] Git Thermite integration with Iceberg

by Ronie Salgado

Hello, Some time ago I presented Git Thermite in this mailing. Git Thermite is a tool for visualizing Git commits that I am making for my master thesis. Now I have managed to integrate Git Thermite with Iceberg. GitHub page: https://github.com/ronsaldo/pharo-git-thermite Demo video: https://www.youtube.com/watch?v=TdBHpdyFgZE Visualization learning material: https://github.com/ronsaldo/pharo-git-thermite/blob/master/doc/learning-mat… Feedback: https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEl… Pharo 7 installation doIt: Metacello new baseline: 'Thermite'; repository: 'github://ronsaldo/pharo-git-thermite/src'; load Please, I would love to get some usage feedback through the Google form :-) Best regards, Ronie

Dec. 12, 2018

Pharo 7 under Linux

by Konrad Hinsen

Hi everyone, I haven't had much success running Pharo 7 under Linux as follows: Â 1. Install pharo-launcher Â 2. Start pharo-launcher Â 3. Create an image for the Pharo 7 development release Â 4. Start that image. It crashes at startup, claiming that libgit2 is missing. There is, however, a libgit2 located at Â Â $HOME/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/libgit2.so Is this a known problem? Is there a workaround? Thanks in advance, Â Konrad.

Dec. 12, 2018

Re: [Pharo-users] [pharo7] loading mcz files

by Guillermo Polito

PR with fix: https://github.com/pharo-project/pharo/pull/2062 On Wed, Dec 12, 2018 at 3:46 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I've opened an issue here: > > > https://pharo.fogbugz.com/f/cases/22754/Exception-while-opening-a-MCSubDire… > > The reason is that several parts of monticello were updated to use the new > file streams, but MCSubdirectory was not. > I'll be posting a fix in a couple of minutes. > > On Wed, Dec 12, 2018 at 3:24 PM Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi Hans, >> >> I'm trying to reproduce this one. It seems it happens only with a >> "Directory with subdirectories" kind of repository. Can you confirm? >> I do now know exactly what this should do, never used it before. >> >> I'll check it and come back to you. >> >> Guille >> >> On Wed, Dec 12, 2018 at 12:46 PM Baveco, Hans <hans.baveco(a)wur.nl> wrote: >> >>> It appeared impossible to load any packages (mcz files) from a >>> MCFileRepositoryInspector, in a recent pharo (moose) 7 image (on windows >>> 7), stack below. Apparently, somewhere a Character null is encountered >>> where an integer is expected... >>> >>> Any ideas how to solve this? >>> >>> TIA, Hans >>> >>> >>> >>> Character(Object)>>doesNotUnderstand: #bitOr: >>> SmallInteger>>bitOr: >>> ZnEndianessReadWriteStream>>nextLittleEndianNumber: >>> ZipArchive>>readEndOfCentralDirectoryFrom: >>> ZipArchive>>readFrom: >>> MCMczReader>>zip >>> MCMczReader>>parseMember: >>> MCMczReader>>loadPackage >>> MCMczReader(MCVersionReader)>>package >>> MCMczReader(MCVersionReader)>>basicVersion >>> MCMczReader(MCVersionReader)>>version >>> [ :r | r version ] in >>> MCSubDirectoryRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: >>> in Block: [ :r | r version ] >>> [ :s | >>> (MCVersionReader readerClassForFileNamed: aString) >>> ifNotNil: >>> [ :class | aBlock value: (class on: s fileName: (self >>> pathForFileNamed: aString)) ] ] in >>> MCSubDirectoryRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: >>> in Block: [ :s | ... >>> MCSubDirectoryRepository>>readStreamForFileNamed:do: >>> >>> MCSubDirectoryRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: >>> >>> MCSubDirectoryRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: >>> [ self loadVersionFromFileNamed: aFileName ] in >>> MCSubDirectoryRepository(MCFileBasedRepository)>>versionFromFileNamed: in >>> Block: [ self loadVersionFromFileNamed: aFileName ] >>> Dictionary>>at:ifAbsent: >>> MCSubDirectoryRepository(MCFileBasedRepository)>>versionFromFileNamed: >>> [ version := repository versionFromFileNamed: selectedVersion ] in >>> MCFileRepositoryInspector>>version in Block: [ version := repository >>> versionFromFileNamed: sele...etc... >>> BlockClosure>>ensure: >>> CursorWithMask(Cursor)>>showWhile: >>> MCFileRepositoryInspector>>version >>> MCFileRepositoryInspector(MCVersionInspector)>>versionSummary >>> MCFileRepositoryInspector(MCVersionInspector)>>summary >>> MCFileRepositoryInspector(Object)>>perform:withEnoughArguments: >>> RubPluggableTextMorph(RubScrolledTextMorph)>>getTextFromModel >>> RubPluggableTextMorph>>update: >>> [ :aDependent | aDependent update: aParameter ] in >>> MCFileRepositoryInspector(Model)>>changed: in Block: [ :aDependent | >>> aDependent update: aParameter ] >>> DependentsArray>>do: >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Dec. 12, 2018

Re: [Pharo-users] [pharo7] loading mcz files

by Guillermo Polito

I've opened an issue here: https://pharo.fogbugz.com/f/cases/22754/Exception-while-opening-a-MCSubDire… The reason is that several parts of monticello were updated to use the new file streams, but MCSubdirectory was not. I'll be posting a fix in a couple of minutes. On Wed, Dec 12, 2018 at 3:24 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Hans, > > I'm trying to reproduce this one. It seems it happens only with a > "Directory with subdirectories" kind of repository. Can you confirm? > I do now know exactly what this should do, never used it before. > > I'll check it and come back to you. > > Guille > > On Wed, Dec 12, 2018 at 12:46 PM Baveco, Hans <hans.baveco(a)wur.nl> wrote: > >> It appeared impossible to load any packages (mcz files) from a >> MCFileRepositoryInspector, in a recent pharo (moose) 7 image (on windows >> 7), stack below. Apparently, somewhere a Character null is encountered >> where an integer is expected... >> >> Any ideas how to solve this? >> >> TIA, Hans >> >> >> >> Character(Object)>>doesNotUnderstand: #bitOr: >> SmallInteger>>bitOr: >> ZnEndianessReadWriteStream>>nextLittleEndianNumber: >> ZipArchive>>readEndOfCentralDirectoryFrom: >> ZipArchive>>readFrom: >> MCMczReader>>zip >> MCMczReader>>parseMember: >> MCMczReader>>loadPackage >> MCMczReader(MCVersionReader)>>package >> MCMczReader(MCVersionReader)>>basicVersion >> MCMczReader(MCVersionReader)>>version >> [ :r | r version ] in >> MCSubDirectoryRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: >> in Block: [ :r | r version ] >> [ :s | >> (MCVersionReader readerClassForFileNamed: aString) >> ifNotNil: >> [ :class | aBlock value: (class on: s fileName: (self >> pathForFileNamed: aString)) ] ] in >> MCSubDirectoryRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: >> in Block: [ :s | ... >> MCSubDirectoryRepository>>readStreamForFileNamed:do: >> >> MCSubDirectoryRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: >> MCSubDirectoryRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: >> [ self loadVersionFromFileNamed: aFileName ] in >> MCSubDirectoryRepository(MCFileBasedRepository)>>versionFromFileNamed: in >> Block: [ self loadVersionFromFileNamed: aFileName ] >> Dictionary>>at:ifAbsent: >> MCSubDirectoryRepository(MCFileBasedRepository)>>versionFromFileNamed: >> [ version := repository versionFromFileNamed: selectedVersion ] in >> MCFileRepositoryInspector>>version in Block: [ version := repository >> versionFromFileNamed: sele...etc... >> BlockClosure>>ensure: >> CursorWithMask(Cursor)>>showWhile: >> MCFileRepositoryInspector>>version >> MCFileRepositoryInspector(MCVersionInspector)>>versionSummary >> MCFileRepositoryInspector(MCVersionInspector)>>summary >> MCFileRepositoryInspector(Object)>>perform:withEnoughArguments: >> RubPluggableTextMorph(RubScrolledTextMorph)>>getTextFromModel >> RubPluggableTextMorph>>update: >> [ :aDependent | aDependent update: aParameter ] in >> MCFileRepositoryInspector(Model)>>changed: in Block: [ :aDependent | >> aDependent update: aParameter ] >> DependentsArray>>do: >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Dec. 12, 2018

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

by Ben Coman

On Wed, 12 Dec 2018 at 19:10, Richard O'Keefe <raoknz(a)gmail.com> wrote: > PS: converting the result of MD5 hashMessage: to hex is a total waste of > time. > Just ask: > - is the first byte zero? > - is the second byte zero? > - is the third byte less than 16? > Good point. cheers -ben > > On Thu, 13 Dec 2018 at 00:07, Richard O'Keefe <raoknz(a)gmail.com> wrote: > >> 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] [pharo7] loading mcz files

by Guillermo Polito

Hi Hans, I'm trying to reproduce this one. It seems it happens only with a "Directory with subdirectories" kind of repository. Can you confirm? I do now know exactly what this should do, never used it before. I'll check it and come back to you. Guille On Wed, Dec 12, 2018 at 12:46 PM Baveco, Hans <hans.baveco(a)wur.nl> wrote: > It appeared impossible to load any packages (mcz files) from a > MCFileRepositoryInspector, in a recent pharo (moose) 7 image (on windows > 7), stack below. Apparently, somewhere a Character null is encountered > where an integer is expected... > > Any ideas how to solve this? > > TIA, Hans > > > > Character(Object)>>doesNotUnderstand: #bitOr: > SmallInteger>>bitOr: > ZnEndianessReadWriteStream>>nextLittleEndianNumber: > ZipArchive>>readEndOfCentralDirectoryFrom: > ZipArchive>>readFrom: > MCMczReader>>zip > MCMczReader>>parseMember: > MCMczReader>>loadPackage > MCMczReader(MCVersionReader)>>package > MCMczReader(MCVersionReader)>>basicVersion > MCMczReader(MCVersionReader)>>version > [ :r | r version ] in > MCSubDirectoryRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: > in Block: [ :r | r version ] > [ :s | > (MCVersionReader readerClassForFileNamed: aString) > ifNotNil: > [ :class | aBlock value: (class on: s fileName: (self > pathForFileNamed: aString)) ] ] in > MCSubDirectoryRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: > in Block: [ :s | ... > MCSubDirectoryRepository>>readStreamForFileNamed:do: > > MCSubDirectoryRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: > MCSubDirectoryRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: > [ self loadVersionFromFileNamed: aFileName ] in > MCSubDirectoryRepository(MCFileBasedRepository)>>versionFromFileNamed: in > Block: [ self loadVersionFromFileNamed: aFileName ] > Dictionary>>at:ifAbsent: > MCSubDirectoryRepository(MCFileBasedRepository)>>versionFromFileNamed: > [ version := repository versionFromFileNamed: selectedVersion ] in > MCFileRepositoryInspector>>version in Block: [ version := repository > versionFromFileNamed: sele...etc... > BlockClosure>>ensure: > CursorWithMask(Cursor)>>showWhile: > MCFileRepositoryInspector>>version > MCFileRepositoryInspector(MCVersionInspector)>>versionSummary > MCFileRepositoryInspector(MCVersionInspector)>>summary > MCFileRepositoryInspector(Object)>>perform:withEnoughArguments: > RubPluggableTextMorph(RubScrolledTextMorph)>>getTextFromModel > RubPluggableTextMorph>>update: > [ :aDependent | aDependent update: aParameter ] in > MCFileRepositoryInspector(Model)>>changed: in Block: [ :aDependent | > aDependent update: aParameter ] > DependentsArray>>do: > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Dec. 12, 2018

[pharo7] loading mcz files

by Baveco, Hans

It appeared impossible to load any packages (mcz files) from a MCFileRepositoryInspector, in a recent pharo (moose) 7 image (on windows 7), stack below. Apparently, somewhere a Character null is encountered where an integer is expected... Any ideas how to solve this? TIA, Hans Character(Object)>>doesNotUnderstand: #bitOr: SmallInteger>>bitOr: ZnEndianessReadWriteStream>>nextLittleEndianNumber: ZipArchive>>readEndOfCentralDirectoryFrom: ZipArchive>>readFrom: MCMczReader>>zip MCMczReader>>parseMember: MCMczReader>>loadPackage MCMczReader(MCVersionReader)>>package MCMczReader(MCVersionReader)>>basicVersion MCMczReader(MCVersionReader)>>version [ :r | r version ] in MCSubDirectoryRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: in Block: [ :r | r version ] [ :s | (MCVersionReader readerClassForFileNamed: aString) ifNotNil: [ :class | aBlock value: (class on: s fileName: (self pathForFileNamed: aString)) ] ] in MCSubDirectoryRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: in Block: [ :s | ... MCSubDirectoryRepository>>readStreamForFileNamed:do: MCSubDirectoryRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do: MCSubDirectoryRepository(MCFileBasedRepository)>>loadVersionFromFileNamed: [ self loadVersionFromFileNamed: aFileName ] in MCSubDirectoryRepository(MCFileBasedRepository)>>versionFromFileNamed: in Block: [ self loadVersionFromFileNamed: aFileName ] Dictionary>>at:ifAbsent: MCSubDirectoryRepository(MCFileBasedRepository)>>versionFromFileNamed: [ version := repository versionFromFileNamed: selectedVersion ] in MCFileRepositoryInspector>>version in Block: [ version := repository versionFromFileNamed: sele...etc... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: MCFileRepositoryInspector>>version MCFileRepositoryInspector(MCVersionInspector)>>versionSummary MCFileRepositoryInspector(MCVersionInspector)>>summary MCFileRepositoryInspector(Object)>>perform:withEnoughArguments: RubPluggableTextMorph(RubScrolledTextMorph)>>getTextFromModel RubPluggableTextMorph>>update: [ :aDependent | aDependent update: aParameter ] in MCFileRepositoryInspector(Model)>>changed: in Block: [ :aDependent | aDependent update: aParameter ] DependentsArray>>do:

Dec. 12, 2018

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

by Richard O'Keefe

PS: converting the result of MD5 hashMessage: to hex is a total waste of time. Just ask: - is the first byte zero? - is the second byte zero? - is the third byte less than 16? On Thu, 13 Dec 2018 at 00:07, Richard O'Keefe <raoknz(a)gmail.com> wrote: > 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