- Pharo-users - lists.pharo.org

Re: [Pharo-users] Brisbane

by Offray Vladimir Luna CÃ¡rdenas

Hi Jeff, Congrats for this initiative. We are creating a local group here in Colombia, mainly in our Hackerspace [1] (Universities here have forgotten about Pharo/Smalltalk an are incredible bureaucratic and slow). Our approach involves data storytelling and agile visualization, with a particular emphasis on data activism. Some details of it are on [2] and the memories (in Spanish) in [3][4], because we have a local first approach. I'm slowly creating English content, like the main page [5], a new user manual[6] and intro pages for the projects repositories[7][8]. [1] http://hackbo.co/ [2] https://pharoweekly.wordpress.com/2016/10/26/about-alternate-ways-to-teach-… [3] http://mutabit.com/dataweek/ [4] http://mutabit.com/repos.fossil/dataweek/ [5] http://mutabit.com/grafoscopio/index.en.html [6] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/ma… [7] http://mutabit.com/repos.fossil/grafoscopio/ [8] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Packages/Dataviz/intro.… Sharing our experience and approaches can help in the consolidation of our local groups. So I hope this helps, and let us know how things are going with your meetup. Cheers, Offray On 06/04/17 19:34, Jeff Gray wrote: > Hi all, > Just an update. I just attended my third Smalltalk meet-up in Brisbane. > It's a small group but hopefully we can grow as we gain momentum. > We are just now setting up our team and initial project in Smalltalk Hub. > > We are meeting once a month in a great little venue by the river with free > fast Wi-Fi and good cheap coffee. > > I have been just hacking in Pharo on my own for a while now. I am looking > forward to working in a team environment, adding some rigour to my testing > and sharing techniques and approaches. > > > > > -- > View this message in context: http://forum.world.st/Brisbane-tp4941489.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 7, 2017

Brisbane

by Jeff Gray

Hi all, Just an update. I just attended my third Smalltalk meet-up in Brisbane. It's a small group but hopefully we can grow as we gain momentum. We are just now setting up our team and initial project in Smalltalk Hub. We are meeting once a month in a great little venue by the river with free fast Wi-Fi and good cheap coffee. I have been just hacking in Pharo on my own for a while now. I am looking forward to working in a team environment, adding some rigour to my testing and sharing techniques and approaches. -- View this message in context: http://forum.world.st/Brisbane-tp4941489.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 7, 2017

Re: [Pharo-users] Voyage and attributes references

by Norbert Hartl

> Am 06.04.2017 um 18:41 schrieb Hilaire <hilaire(a)drgeo.eu>: > > Le 06/04/2017 Ã 16:14, Norbert Hartl a Ã©crit : >>> One idea will be to have collection of Address, but this really looks >>> strange to me. >>> >> why? >> > > It looks like a painful scenario: Address is most of the time referenced > by only one object, but in one scenario I need a shared attributes. > Because of this it implies to overlook for #save and #remove messages to > Address instances all around, forgetting some leading to bugs. But there > are not alternative I guess? Or to have two Address class, one set as a > root. Not sure what is the best practice. > Not sure either. But I think having a SharedAddress class is worth a try. The other possibility would be if #voyageRoot would be also instance side. Right now I don't have a computer to check. Norbert > Hilaire > > -- > Dr. Geo > http://drgeo.eu > >

April 6, 2017

Re: [Pharo-users] Voyage and attributes references

by Hilaire

Le 06/04/2017 Ã 16:14, Norbert Hartl a Ã©crit : >> One idea will be to have collection of Address, but this really looks >> strange to me. >> > why? > It looks like a painful scenario: Address is most of the time referenced by only one object, but in one scenario I need a shared attributes. Because of this it implies to overlook for #save and #remove messages to Address instances all around, forgetting some leading to bugs. But there are not alternative I guess? Or to have two Address class, one set as a root. Not sure what is the best practice. Hilaire -- Dr. Geo http://drgeo.eu

April 6, 2017

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