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

Re: [Pharo-users] Voyage and attributes references

by Norbert Hartl

Hi, > Am 06.04.2017 um 15:54 schrieb Hilaire <hilaire(a)drgeo.eu>: > > Hi, > > Here is another scenario where I have trouble with Voyage: > > Let's an object A, with an attribute an object Address. > Then I create B, a copy of A. > > Of course the object Address is both an attribute of A and B. (no deep > copy). > > As long as my Voyage repo is running, editing Address from A or B is > doing fine: when editing Address from A, I can see this reflected in B's > Address, as expected. > > Sadly, this Object scheme is lost in the persistency: when I reset the > repo, shutdown it, restart it, to force a full retrieve from the Mongo > repo, object A and B do not share anymore the Address object has it > should be. > > I understand Voyage is not a true really Object Oriented repository, but > is it possible to overcome such limitation? > The Adress object must voyageRoot in order for this to work. If an object is voyageRoot it is kept as identity being a separate object living in a collection that can be referenced. If it is not voyageRoot you store a copy of the object each them because that object gets embedded into the container object. > One idea will be to have collection of Address, but this really looks > strange to me. > why? > I think Fuel was doing just fine with such scenario, but sadly Fuel is > not reliable between images. > Fuel stores the object graph as it is. It is hard to compare because you cannot search a fuel dump. I think the question is what you need. If it is having a partial graph in memory that has been extracted from the whole graph through query then you have a pretty decent need for a database and a tool like voyage. If you just need to persist you are better off with fuel. And if you need the same to be reliable between two images use STON. > Thanks to read up to here. > You're welcome! :) Norbert > Hilaire > > -- > Dr. Geo > http://drgeo.eu > >

April 6, 2017

Voyage and attributes references

by Hilaire

Hi, Here is another scenario where I have trouble with Voyage: Let's an object A, with an attribute an object Address. Then I create B, a copy of A. Of course the object Address is both an attribute of A and B. (no deep copy). As long as my Voyage repo is running, editing Address from A or B is doing fine: when editing Address from A, I can see this reflected in B's Address, as expected. Sadly, this Object scheme is lost in the persistency: when I reset the repo, shutdown it, restart it, to force a full retrieve from the Mongo repo, object A and B do not share anymore the Address object has it should be. I understand Voyage is not a true really Object Oriented repository, but is it possible to overcome such limitation? One idea will be to have collection of Address, but this really looks strange to me. I think Fuel was doing just fine with such scenario, but sadly Fuel is not reliable between images. Thanks to read up to here. Hilaire -- Dr. Geo http://drgeo.eu

April 6, 2017

Re: [Pharo-users] using UFFI in non-crashing way

by Denis Kudriashov

2017-04-06 10:37 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > But then the problem is on "how to not lose your code", not in FFI... > > > Restarting image is a problem. For any other "smalltalk" problems we got > suitable debugger but not in that case. Also when image crashed we need to recover all objects state for the script which produce crash

April 6, 2017

Re: [Pharo-users] using UFFI in non-crashing way

by Denis Kudriashov

2017-03-27 13:01 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > But then the problem is on "how to not lose your code", not in FFI... Restarting image is a problem. For any other "smalltalk" problems we got suitable debugger but not in that case.

April 6, 2017

Re: [Pharo-users] PetitParser question parsing HTML meta tags

by Paul DeBruicker

Thanks. I really appreciate everyone's help on this. Was at a high level of frustration the other day. monty-3 wrote > You could use XMLHTMLParser from STHub PharoExtras/XMLParserHTML > (supported on Pharo, Squak, and GS): > > descriptions := OrderedCollection new. > (XMLHTMLParser parseURL: aURL) > allElementsNamed: 'meta' > do: [:each | > ((each attributeAt: 'name') asLowercase = 'description' > or: [(each attributeAt: 'http-equiv') asLowercase = 'description']) > ifTrue: [descriptions addLast: (each attributeAt: 'content')]]. > > it accepts messy HTML and produces an XML DOM tree from it. > >> Sent: Thursday, March 30, 2017 at 1:58 PM >> From: "PAUL DEBRUICKER" < > pdebruic@ > > >> To: "Any question about pharo is welcome" < > pharo-users@.pharo > > >> Subject: [Pharo-users] PetitParser question parsing HTML meta tags >> >> This is kind of a "I'm tired of thinking about this and not making much >> progress for the amount of time I'm putting in question" but here it is: >> >> >> >> I'm trying to parse descriptions from HTML meta elements. I can't use >> Soup because there isn't a working GemStone port. >> >> I've got it to work with the structure: >> >> > <meta name="description" content="my description"> >> >> and >> >> > <meta name="Description" content="my description"> >> >> >> but I'm running into instances of: >> >> > <meta http-equiv="description" content="my description"> >> >> and >> >> > <meta http-equiv="Description" content="my description"> >> >> >> and am having trouble adapting my parsing code (such as it is). >> >> >> The parsing code that addresses the first two cases is: >> >> >> >> parseHtmlPageForDescription: htmlString >> | startParser endParser ppStream descParser result text lower str >> doubleQuoteIndex | >> lower := 'escription' asParser. >> startParser := ' > <meta name=' asParser , #'any' asParser , #'any' asParser. >> > endParser := '>' asParser. >> ppStream := htmlString readStream asPetitStream. >> descParser := ((#'any' asParser starLazy: startParser , lower) >> , (#'any' asParser starLazy: endParser)) ==> #'second'. >> result := descParser parse: ppStream. >> text := (result >> inject: (WriteStream on: String new) >> into: [ :stream :char | >> stream nextPut: char. >> stream ]) >> contents trimBoth. >> str := text copyFrom: (text findString: 'content=') + 9 to: text size. >> doubleQuoteIndex := 8 - ((str last: 7) indexOf: $"). >> ^ str copyFrom: 1 to: str size - doubleQuoteIndex >> >> >> I can't figure out how to change the startParser parser to accept the >> second idiom. And maybe there's a better approach altogether. Anyway. >> If anyone has any ideas on different approaches I'd appreciate learning >> them. >> >> >> Thanks for giving it some thought >> >> Paul >> -- View this message in context: http://forum.world.st/PetitParser-question-parsing-HTML-meta-tags-tp4940587… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 5, 2017

Re: [Pharo-users] Build Pharo VM with --dynamic-linker

by Alistair Grant

Hi Luke, On 5 April 2017 at 10:41, Luke Gorrie <luke(a)snabb.co> wrote: > Hi Alistair, > > Just an idea: One alternative could be to use patchelf [1] to modify the > dynamic library path in an existing binary. My understanding is that this > method is very robust and widely used. > > [1]: https://nixos.org/patchelf.html Brilliant! That does the trick, thanks! Cheers, Alistair > On 5 April 2017 at 09:14, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi All, >> >> I'm still working on getting Pharo packaged with snapcraft. The latest >> hurdle is that 32 bit applications won't load correctly because the >> snapcraft environment means that ld-linux.so.2 isn't in the expected >> location. >> >> My understanding is that adding the appropriate --dynamic-linker flag >> should solve the problem, defining: >> >> export LDFLAGS="-Wl,--dynamic-linker=/snap/pharo/x1/lib/ld-linux.so.2" >> >> successfully builds, but the pharo executable still has the default >> location: >> >> $ strings pharo-vm/pharo | grep ld-linux >> /lib/ld-linux.so.2 >> >> Can someone point me to where I should modify the build scipt(s) so I >> can set --dynamic-linker appropriately? >> >> >> Thanks! >> Alistair >> >

April 5, 2017

Re: [Pharo-users] Build Pharo VM with --dynamic-linker

by Luke Gorrie

Hi Alistair, Just an idea: One alternative could be to use patchelf [1] to modify the dynamic library path in an existing binary. My understanding is that this method is very robust and widely used. [1]: https://nixos.org/patchelf.html On 5 April 2017 at 09:14, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi All, > > I'm still working on getting Pharo packaged with snapcraft. The latest > hurdle is that 32 bit applications won't load correctly because the > snapcraft environment means that ld-linux.so.2 isn't in the expected > location. > > My understanding is that adding the appropriate --dynamic-linker flag > should solve the problem, defining: > > export LDFLAGS="-Wl,--dynamic-linker=/snap/pharo/x1/lib/ld-linux.so.2" > > successfully builds, but the pharo executable still has the default > location: > > $ strings pharo-vm/pharo | grep ld-linux > /lib/ld-linux.so.2 > > Can someone point me to where I should modify the build scipt(s) so I > can set --dynamic-linker appropriately? > > > Thanks! > Alistair > >

April 5, 2017

Build Pharo VM with --dynamic-linker

by Alistair Grant

Hi All, I'm still working on getting Pharo packaged with snapcraft. The latest hurdle is that 32 bit applications won't load correctly because the snapcraft environment means that ld-linux.so.2 isn't in the expected location. My understanding is that adding the appropriate --dynamic-linker flag should solve the problem, defining: export LDFLAGS="-Wl,--dynamic-linker=/snap/pharo/x1/lib/ld-linux.so.2" successfully builds, but the pharo executable still has the default location: $ strings pharo-vm/pharo | grep ld-linux /lib/ld-linux.so.2 Can someone point me to where I should modify the build scipt(s) so I can set --dynamic-linker appropriately? Thanks! Alistair

April 5, 2017

Neural Networks in Pharo

by Oleksandr Zaytsev

Hello! Several weeks ago I've announced my NeuralNetworks project. Thank you very much for your ideas and feedback. As suggested, I wrote examples for every class and tested my perceptron on linearly-separable logical functions. I have just completed a post about my implementation of a single-layer perceptron: https://medium.com/@i.oleks/single-layer-perceptron-in-pharo-5b13246a041d. It has a detailed explanation of every part of the design and illustrates different approaches to implementation. Please, tell me what you think. Are my class diagrams correct or did I mess something up? Is there a design pattern that I should consider? Do you think that I should do something differently? Should I improve the quality of my code? Yours sincerely, Oleksandr

April 5, 2017

Re: [Pharo-users] FileReference / and parent

by Alistair Grant

Hi Stef, On Tue, Apr 04, 2017 at 04:33:56PM +0200, Stephane Ducasse wrote: > Hi alistair > > We should target Pharo 70. Yep, I saw Esteban's message saying he hopes 6.0 is only a week away, so this can definitely wait. > Now it is great that you help improving the file frameworks. > Could you open a bug entry? Yep, I was just waiting to see if there was lots of resistance to these changes (which there doesn't seem to be). > Do you have tests? I was working on them when this email arrived. :-) I expect it will take me a week to get them to the point I'm happy (this is a part time hobby), but they'll definitely be part of the slice / pull request when I submit it. Cheers, Alistair > > Stef > > On Mon, Apr 3, 2017 at 2:04 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > > Hi All, > > > > I previously suggested a change to Path>>/ which actually covered two > > issues: > > > > 1. The handling of the parent directory notation, i.e. ".." > > 2. The construction of path segments when appending a string. > > > > As Damien pointed out, the first issue needs a bit more consideration. > > > > I think the second point is still problematic and can be addressed > > separately. In particular: > > > > ('/a/b/c' asFileReference / 'd/e/f') parent "File @ /a/b/c" > > > > I would expect the result to be "File @ /a/b/c/d/e" > > > > The fix is straightforward (although someone may be able to propose a > > more elgant solution): > > > > -- > > / aString > > | path additionalPath index | > > > > aString isEmptyOrNil > > ifTrue: [ Error signal: 'Path element cannot be empty or > > nil']. > > > > additionalPath := Path from: aString. > > path := self class new: self size + additionalPath size. > > path copyFrom: self. > > index := self size + 1. > > additionalPath do: [ :each | > > path at: index put: each. > > index := index + 1. > > ]. > > ^ path > > -- > > > > 1. Do you agree with the proposed change? > > 2. (Assuming you agree): Should we target Pharo 6.0 or 7.0? > > On one side, this is clearly a bug, on the other, no one has reported > > it to date, so it isn't having a big impact. > > > > Thanks, > > Alistair > > > >

April 4, 2017