December 2018 - Pharo-users

Re: [Pharo-users] can I improve this

by Roelof Wobben

Dec. 3, 2018

Re: [Pharo-users] UFFI and opaque(ish) types

by phil＠highoctane.be

Alistair, I also would like to see how this works. https://github.com/estebanlm/TalkFFI There is also https://github.com/Pharophile/swig https://github.com/Pharophile/swig/tree/master/Lib/pharo (actually this is a fork from Ronie's work) that does some Pharo magic for bindings. And https://github.com/pavel-krivanek/CCodeGenerator may help to generate some quick external things to reload (it is Slang externalized). We need a solid push on all of this front since it takes wayyy too much time to produce a binding. It is error prone, boring, and frankly UFFI deserves better given its power. Best, Phil On Mon, Dec 3, 2018 at 10:27 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Ben and Phil, > > Thanks for your replies. > > On Sun, Dec 02, 2018 at 10:53:11PM +0800, Ben Coman wrote: > > One option could be to create a small shared library that you compile > for each > > platform that just exported the member offsets... > > https://www.embedded.com/design/prototyping-and-development/4024941/ > > Learn-a-new-trick-with-the-offsetof--macro > > > > You first FFI to that read struct member offsets and dynamically create > the > > definitions for your target library. > > I haven't tried it in practice. > > > > cheers -ben > > > > P.S. Occasionally I dream about compilers being able to embed a > pre-compiled > > header declaration block in the library for FFI users to iterate... > > https://clang.llvm.org/docs/PCHInternals.html#declarations-block > > > > On Sun, Dec 02, 2018 at 04:41:38PM +0100, phil(a)highoctane.be wrote: > > No, but what about FFIExternalPackedStructureTest and FFITestStructure ? > > > > Never tried with a typedef in the fieldsDesc but may work. > > > > Phil > > > OK, it sounds like this still hasn't been adressed. > > The other idea that we've discussed in the past is to supply human > readable text files that describe the structures for each platform, e.g. > a STON file. The file would be generated by automatically creating a > program that dumps the required information to the STON text file. This > would allow the definitions to be used on platforms that don't have a > compiler or the dev versions of the libraries installed. I think we > could even use the current #fieldDesc methods to generate these programs > (maybe with some additional information stored in the class). > > A couple of links: > > - > http://forum.world.st/PATCH-added-FilePlugin-error-code-lookup-function-tp5… > - > http://forum.world.st/PATCH-added-FilePlugin-error-code-lookup-function-tp5… > > > Thanks again, > Alistair > > > >

Dec. 3, 2018

Re: [Pharo-users] UFFI and opaque(ish) types

by Alistair Grant

Hi Ben and Phil, Thanks for your replies. On Sun, Dec 02, 2018 at 10:53:11PM +0800, Ben Coman wrote: > One option could be to create a small shared library that you compile for each > platform that just exported the member offsets... > https://www.embedded.com/design/prototyping-and-development/4024941/ > Learn-a-new-trick-with-the-offsetof--macro > > You first FFI to that read struct member offsets and dynamically create the > definitions for your target library. > I haven't tried it in practice. > > cheers -ben > > P.S. Occasionally I dream about compilers being able to embed a pre-compiled > header declaration block in the library for FFI users to iterate... > https://clang.llvm.org/docs/PCHInternals.html#declarations-block On Sun, Dec 02, 2018 at 04:41:38PM +0100, phil(a)highoctane.be wrote: > No, but what about FFIExternalPackedStructureTest and FFITestStructure ? > > Never tried with a typedef in the fieldsDesc but may work. > > Phil OK, it sounds like this still hasn't been adressed. The other idea that we've discussed in the past is to supply human readable text files that describe the structures for each platform, e.g. a STON file. The file would be generated by automatically creating a program that dumps the required information to the STON text file. This would allow the definitions to be used on platforms that don't have a compiler or the dev versions of the libraries installed. I think we could even use the current #fieldDesc methods to generate these programs (maybe with some additional information stored in the class). A couple of links: - http://forum.world.st/PATCH-added-FilePlugin-error-code-lookup-function-tp5… - http://forum.world.st/PATCH-added-FilePlugin-error-code-lookup-function-tp5… Thanks again, Alistair

Dec. 3, 2018

Re: [Pharo-users] can I improve this

by Richard O'Keefe

Roelof Wobben wrote "I have to reread the file till the adding causes the same outcome as we had already" You have to process the *sequence of changes* repeatedly; you DON't have to *reread the file*. Somebody already made this point. Having read the changes into an array, you can iterate repeatedly over that array. to find the first repeated frequency given a sequence of changes make an empty Set to hold the sums that have been seen so far. set the frequency to 0. loop forever for each change in the changes increment the frequency by the change. if the frequency is in the set return the frequency otherwise add the frequency to the set. partTwo: aFileName Transcript print: (self firstRepeatedFrequency: (self changesFrom: aFileName)); cr; flush. On Mon, 3 Dec 2018 at 19:31, Roelof Wobben <r.wobben(a)home.nl> wrote: > Thanks, > > For the second I have to take a good look. > > I have to reread the file till the adding causes the same outcome as we > had already > > so for example if we have the sequence : > > +3, +3, +4, -2, -4 > > it has as outcome : > > 3 6 10 8 4 > > so no outcome is there a second time so we repeat the sequence > > > 7 10 > > the 10 shows up a second time so there we have our answer. > > > Roelof > > > > Op 3-12-2018 om 03:45 schreef Richard O'Keefe: > > The key question is "what do you mean by improve"? > I'd start by asking "what are you doing that you will still have to do in > part 2, and what won't you do?" So looking at part 2, you will want to > convert the lines to integers, and > input := Array streamContents: [:lines | > 'input.txt' asFileReference readStreamDo: [:in | > [in atEnd] whileFalse: [lines nextPut: in nextLine asInteger]]]. > gives you a chunk of code you can use in both parts. So you might > want to have > > Day1 > changesFrom: aFileName > ^Array streamContents: [:changes | > aFileName asFileReference readStreamDo: [:in | > [in atEnd] whileFalse: [changes nextPut: in nextLine asInteger]]] > partOne: aFileName > ^(self changesFrom: aFileName) sum > partTwo: aFileName > ... > The file name should not be wired in because you want some test files. > > > >

Dec. 3, 2018

Re: [Pharo-users] [Pharo-dev] [Ann] Fog 1.0.0-beta

by Santiago Bragagnolo

It was late yesterday hahaha, I made many mistakes, thanks Marcus. Anyway, the address is this one: https://github.com/smartanvil/Fog <https://github.com/sbragagnolo/Fog> El lun., 3 de dic. de 2018 09:12, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > Link to GitHub: > > https://github.com/smartanvil/Fog <https://github.com/sbragagnolo/Fog> > > On 3 Dec 2018, at 01:20, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > wrote: > > Hi All! > > I have being working on releasing versions (i should do it more often). > I am happy to announce Fog v1.0.0-beta. I think I found a API that i like > enough. So, i took the courage to pass to 1. > > Thew new version changes many things: Redefines the roll of the session, > it minimize the roll of the connection, it cleans up the code, it defines a > more verbose but less magic API. It generates proxies for the contracts. > > It supports now all the types including: maps and arrays. > > Goodnight :) > > > Santiago > > > Fog > > Pharo Ethereum Driver > > Fog is a library that allows the user to connect to an ethereum based > blockchain data base. > > Is based on the Javascript canonical implementation done by Ethereum > community Ethereum Javascript API > <https://github.com/ethereum/wiki/wiki/JavaScript-API>. > <https://github.com/smartanvil/Fog#dependencies> > Download code <https://github.com/smartanvil/Fog#iceberg--baseline>Iceberg > / Baseline > > Metacello > new > baseline: 'Fog'; > repository: 'github://sbragagnolo/Fog/src'; > load. > > >

Dec. 3, 2018

Re: [Pharo-users] [Pharo-dev] [Ann] Fog 1.0.0-beta

by Marcus Denker

Link to GitHub: https://github.com/sbragagnolo/Fog <https://github.com/sbragagnolo/Fog> > On 3 Dec 2018, at 01:20, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > > Hi All! > > I have being working on releasing versions (i should do it more often). > I am happy to announce Fog v1.0.0-beta. I think I found a API that i like enough. So, i took the courage to pass to 1. > > Thew new version changes many things: Redefines the roll of the session, it minimize the roll of the connection, it cleans up the code, it defines a more verbose but less magic API. It generates proxies for the contracts. > > It supports now all the types including: maps and arrays. > > Goodnight :) > > > Santiago > > > Fog > > Pharo Ethereum Driver > > Fog is a library that allows the user to connect to an ethereum based blockchain data base. > > Is based on the Javascript canonical implementation done by Ethereum community Ethereum Javascript API <https://github.com/ethereum/wiki/wiki/JavaScript-API>. > > <https://github.com/smartanvil/Fog#dependencies> > Download code > > <https://github.com/smartanvil/Fog#iceberg--baseline>Iceberg / Baseline > > Metacello > new > baseline: 'Fog'; > repository: 'github://sbragagnolo/Fog/src'; > load.

Dec. 3, 2018

Re: [Pharo-users] can I improve this

by Roelof Wobben

Dec. 3, 2018

Re: [Pharo-users] can I improve this

by phil＠highoctane.be

Also, given the time that some people solve the puzzle, doing it too nice is actually not the best use of time in AoC. Now, I'll try to solve quick and this will for sure lead to interesting things in Pharo. >From Reddit, people solve it quick then make it nice. Phil On Mon, Dec 3, 2018, 03:45 Richard O'Keefe <raoknz(a)gmail.com wrote: > The key question is "what do you mean by improve"? > I'd start by asking "what are you doing that you will still have to do in > part 2, and what won't you do?" So looking at part 2, you will want to > convert the lines to integers, and > input := Array streamContents: [:lines | > 'input.txt' asFileReference readStreamDo: [:in | > [in atEnd] whileFalse: [lines nextPut: in nextLine asInteger]]]. > gives you a chunk of code you can use in both parts. So you might > want to have > > Day1 > changesFrom: aFileName > ^Array streamContents: [:changes | > aFileName asFileReference readStreamDo: [:in | > [in atEnd] whileFalse: [changes nextPut: in nextLine asInteger]]] > partOne: aFileName > ^(self changesFrom: aFileName) sum > partTwo: aFileName > ... > The file name should not be wired in because you want some test files. > > >

Dec. 3, 2018

Re: [Pharo-users] can I improve this

by Roelof Wobben

Dec. 3, 2018

Re: [Pharo-users] can I improve this

by Richard O'Keefe

The key question is "what do you mean by improve"? I'd start by asking "what are you doing that you will still have to do in part 2, and what won't you do?" So looking at part 2, you will want to convert the lines to integers, and input := Array streamContents: [:lines | 'input.txt' asFileReference readStreamDo: [:in | [in atEnd] whileFalse: [lines nextPut: in nextLine asInteger]]]. gives you a chunk of code you can use in both parts. So you might want to have Day1 changesFrom: aFileName ^Array streamContents: [:changes | aFileName asFileReference readStreamDo: [:in | [in atEnd] whileFalse: [changes nextPut: in nextLine asInteger]]] partOne: aFileName ^(self changesFrom: aFileName) sum partTwo: aFileName ... The file name should not be wired in because you want some test files.

Dec. 3, 2018