- Pharo-dev - lists.pharo.org

Is there some RSS parser updated around?

by Mariano Martinez Peck

Hi guys, All the RSS parsers I found are all quite outdated...does someone have an updated one? I want to parse RSS and then display it within Seaside (to render kind of company news). Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Aug. 16, 2017

Re: [Pharo-dev] @About posting here

by Eliot Miranda

Frank, On Wed, Aug 16, 2017 at 3:52 AM, Frank-B <frank.berger.software(a)web.de> wrote: > Phil, > > nice attempt to drill and silence me! My advise: They all failed! > How is Phil's list of the advantages of mailing lists from a phone user (advantages I depend on all the time) an attempt to silence you? > > If somebody can't cope with straight critics or unpopular opinions that > aint > my fault. > Phil cotradicting you is not an example of someone not coping with your opinions, unpopular or otherwise. Quite the opposite. It is an example of rational debate. Phil is introducing the benefits he sees from using mailing lists. He disagrees with you. To me it looks like you who can't cope with his disagreement. Instead of addressing his points you post an extremely subjective response. > > Frank > who never worried about being labeled and > from a country where free speech is still welcome Why is free speech necessarily a national issue? It is also an issue at smaller and larger scales. How is your free speech being impinged upon here? You haven't been blocked. Tudor gave a reasoned request for you to be more civil, which is not bad advice. I myself found your "javascript idiots" shocking, because I can think of no better way of antagonizing the JavaScript community, with which you may have to interact regularly to get help with your project, than writing the entire community off as idiotic. Maybe I misunderstood you. Anyway, I do hope that you can find discussion here more p[roductive and less antagonistic, both in your perceptions and your responses. And more importantly I hope you have productive discussions here. We all stand to benefit from each other if we can collaborate and assist, and that effort is in my experience always helped by clear and courteous communication, especially when opinions differ strongly. > -- > View this message in context: http://forum.world.st/Anybody- > using-Orca-Smalltalk-to-JavaScript-tp4960519p4961628.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > _,,,^..^,,,_ best, Eliot

Aug. 16, 2017

19609 FileReference>>base should be before last separator

by Alistair Grant

Hi All, I've just taken a look at issue 19609 FileReference>>base should be before last separator and wonder whether it is a correct interpretation of the original intentions. The original author of the issue, Michael, seems to feel that FileReferene>>base and FileReference>>basenameWithoutExtension are the same. My reading of the comments is that they perform a different function, i.e.: '/a/b/c.d.e' asFileReference base. "c" '/a/b/c.d.e' asFileReference basenameWithoutExtension. "c.d" are both the expected values, i.e.: - #base answers the name up to the first extensionDelimiter. - #basenameWithoutExtension answers the name without what is typically considered the file extension (the bit after the last extensionDelimiter). Not shown above, but: - #basename answers the entire filename, i.e. "c.d.e". Does anyone know the history of these methods? Cheers, Alistair

Aug. 16, 2017

Re: [Pharo-dev] FileSystem fix integration

by Alistair Grant

Hi Stef, On Wed, Aug 16, 2017 at 08:43:24PM +0200, Stephane Ducasse wrote: > May be you already see it but > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > https://github.com/pharo-project/pharo/pull/137 > has a merge conflict I haven't looked at this at all. I'll try and take a look it at soon (my daughter's birthday party this weekend, so time is limited :-)). > I will integrate now > > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > https://github.com/pharo-project/pharo/pull/133 > > and after when esteban is back we will integrate > > https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… I'm looking forward to this one :-) Cheers, Alistair > On Wed, Aug 16, 2017 at 3:42 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > > > On Wed, Aug 16, 2017 at 12:16:52PM +0200, Stephane Ducasse wrote: > >> I'm integrating 20307 and I would like to really thank you for > >> - the bug entry description > >> - all the comments > >> - and tests in the PR. > >> > >> Tx!!! > > > > Thanks for your kind words. > > > > And for integrating the PR :-) > > > > > > I've re-submitted 20165 Support segment path printing. > > > > So the open list is: > > > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > > - https://github.com/pharo-project/pharo/pull/210 > > Note that this is a different PR from before, see the comments in > > the issue. > > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > > https://github.com/pharo-project/pharo/pull/133 > > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > > https://github.com/pharo-project/pharo/pull/137 > > - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… > > This is the first step in fixing FileReference>>isSymlink and > > extending support for all file attributes returned by stat() and > > lstat(). > > The parent issue is: > > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… > > > > > > Still to be closed (won't fix): > > > > - https://pharo.fogbugz.com/f/cases/18042 > > - https://github.com/pharo-project/pharo/pull/75 > > > > > > And waiting on FFI / kernel resolution: > > > > - https://pharo.fogbugz.com/f/cases/5723/ > > - https://github.com/pharo-project/pharo/pull/92 > > > > > > Cheers, > > Alistair > > > > >

Aug. 16, 2017

Issue that may break Epicea

by Stephane Ducasse

Hi martin https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile https://github.com/pharo-project/pharo/pull/133

Aug. 16, 2017

Re: [Pharo-dev] FileSystem fix integration

by Stephane Ducasse

May be you already see it but - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… https://github.com/pharo-project/pharo/pull/137 has a merge conflict I will integrate now - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile https://github.com/pharo-project/pharo/pull/133 and after when esteban is back we will integrate https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… On Wed, Aug 16, 2017 at 3:42 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On Wed, Aug 16, 2017 at 12:16:52PM +0200, Stephane Ducasse wrote: >> I'm integrating 20307 and I would like to really thank you for >> - the bug entry description >> - all the comments >> - and tests in the PR. >> >> Tx!!! > > Thanks for your kind words. > > And for integrating the PR :-) > > > I've re-submitted 20165 Support segment path printing. > > So the open list is: > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > - https://github.com/pharo-project/pharo/pull/210 > Note that this is a different PR from before, see the comments in > the issue. > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > https://github.com/pharo-project/pharo/pull/133 > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > https://github.com/pharo-project/pharo/pull/137 > - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… > This is the first step in fixing FileReference>>isSymlink and > extending support for all file attributes returned by stat() and > lstat(). > The parent issue is: > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… > > > Still to be closed (won't fix): > > - https://pharo.fogbugz.com/f/cases/18042 > - https://github.com/pharo-project/pharo/pull/75 > > > And waiting on FFI / kernel resolution: > > - https://pharo.fogbugz.com/f/cases/5723/ > - https://github.com/pharo-project/pharo/pull/92 > > > Cheers, > Alistair > >

Aug. 16, 2017

[Pharo 70 ] build 39 - PR 210 20165/Support-segment-path-printing

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing https://github.com/pharo-project/pharo/pull/210 one more :)

Aug. 16, 2017

Re: [Pharo-dev] Ugly smell: really long symbols/selectors

by Richard Sargent

Guillermo Polito wrote > but wait, I've just shown that more than 2/3s of them are not test > selectors... Well, quit teasing us. :-) Show us the list (longest to shortest order). I agree with you that it is a code smell and you are right to be suspicious. I'm inclined to say that if the method name is a novella, the method is probably doing too much or the method name is trying to explain too much about the method's internals. > On Wed, Aug 16, 2017 at 2:21 PM, Denis Kudriashov < > dionisiydk@ > > > wrote: > >> Which is actually shows that tests as methods are not really good idea. >> Tests are supposed to be documentation but with classic SUnit we have >> only >> two ways (classes and methods) to decompose them which is definitely not >> enough for docs. >> But ignore it. I am just thinking aloud :) >> >> 2017-08-16 13:47 GMT+02:00 Stephane Ducasse < > stepharo.self@ > >: >> >>> I often use long selectors for tests :) >>> >>> >>> On Wed, Aug 16, 2017 at 9:49 AM, Guillermo Polito < >>> > guillermopolito@ >> wrote: >>> >>>> (ByteSymbol allInstances select: [ :e | e size > 50 ]) size >>>> "638" >>>> (ByteSymbol allInstances select: [ :e | e size > 50 and: [ e >>>> beginsWith: >>>> 'test' ] ]) size >>>> "200" >>>> >>>> Still 438 non test selectors. Some of them are class creation methods >>>> (#subclass:instanceVariables:...) >>>> >>>> I'm just saying this is a smell, wanted to share some of my catarsis >>>> :). >>>> >>>> Guille >>>> >>>> On Wed, Aug 16, 2017 at 9:35 AM, Nicolas Cellier < >>>> > nicolas.cellier.aka.nice@ >> wrote: >>>> >>>>> Hi Guile, >>>>> have you inspect-ed the list? >>>>> I wouldn't be surprise that these are whole sentence acting as >>>>> specification in unit TestCase, >>>>> like whenBrowserReceiveOpenItShouldReturnTheWindowMorph... >>>>> >>>>> 2017-08-16 3:51 GMT+02:00 Guillermo Polito < > guillermopolito@ > >: >>>>> >>>>>> #'thisIsAVeryLongSelectorAndIfYoureHereWeHaveOnly49ImagineIH >>>>>> aveToWriteAllThisToArriveTo87ThenThisTo100' >>>>>> >>>>>> (ByteSymbol allInstances select: [ :e | e size > 100 ]) size >>>>>> => 36 >>>>>> >>>>>> (ByteSymbol allInstances select: [ :e | e size between: 50 and: 100 >>>>>> ]) >>>>>> size >>>>>> => 653 >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> Guille Polito >>>>>> >>>>>> >>>>>> Research Engineer >>>>>> >>>>>> 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 <+33%206%2052%2070%2066%2013> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> >>>> Research Engineer >>>> >>>> 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 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> > > > -- > > > > Guille Polito > > > Research Engineer > > 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 -- View this message in context: http://forum.world.st/Ugly-smell-really-long-symbols-selectors-tp4961544p49… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 16, 2017

Re: [Pharo-dev] [Vm-dev] File & Socket Handle Access

by Esteban Lorenzano

+1 > On 16 Aug 2017, at 02:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > recently Denis Kudriashov wanted to access the OS handle of a Socket from the image to pass through the FFI. David Lewis pointed out that the AioPlugin provides a primitive to do this. I asked David why he didn't add it to the SocketPlugin in the first place and he discussed Andreas Rabb's security concerns. It strikes me > a) that accessing the OS handle of a file or a socket is extremely useful in some circumstances and invalid in others > b) having handle access in a secondary plugin is inconvenient to say the least > c) having access only to Socket handles and not to file handles is also inconvenient. > > So I propose adding a SecurityPlugin facility to control handle access, which would be granted by default, and to add primitives to both the SocketPlugin and FilePlugin to answer the native OS handle when the SecurityPlugin grants permission. > > I also propose adding a compilation flag to the Windows VM to allow compiling out Andreas' handle management, which consists merely of maintaining a table of the file handles (not the socket handles) that have been created by the VM. It strikes me that a much better solution is merely to encrypt the handle via xoring with a value created at random. I don't see how Andreas' solution adds value, especially since it is not implemented on other platforms, and merely adds overhead. > > Thoughts? Objections? > _,,,^..^,,,_ > best, Eliot

Aug. 16, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Esteban Lorenzano

Hi, In general (you all know me), I have the policy of âdo not go alien just becauseâ which means we do not need to reinvent the wheel all the time and we need to stick with what is already there and known (I have pushed many changes in pharo following this direction, iceberg being just the latest), but we need to keep also the basis of what we are (which means: when we need to stay alien, we need to embrace it too). Said that: while I would LOVE to have a markdown compatible format, the amount of effort put on pillar to make it *what we need* and is a format used not just for doing README.md but to write books, etc., then replacing it would be complicated. butâ¦ I think we can do pillar syntax more âmarkdown alikeâ (and we can even have a stripped-pillar with would be even more like md), I would salute such change. cheers, Esteban > On 15 Aug 2017, at 19:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Aug 15, 2017, at 7:25 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > >> >> >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> You hit several birds with one single mail. >> >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> > Jimmie et al. nicely reasoned arguments - and Doru's point about controlling >> > the syntax is an interesting one that I hadnât thought about. >> > >> > Personally, I find having too many similar syntaxâs confusing - contributing >> > to things is hard enough - having to remember that its !! Instead of ## and >> > ââ instead of ** is just frustrating for me. >> >> +1 >> >> Not only for docs, most platforms like Slack/Discord share the syntax, >> so now I'm getting "muscle memory" when typing literals using the >> backtick (`) character, quoting with > or pasting snippets using ``` >> >> +1. So I've posted this before... >> https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac…> >> describing that "The only strategy in getting people to switch to your product is to eliminate barriers" >> >> But more... the best reason for Pillar to support a Markdown-ish syntax, is that when we scratch-our-own-itch (nominally for Pillar) to build the best damn markup-editor ever (because we can!) - if this happened to support Markdown it can draw in Markdown-non-Pharo users (because its the best editor ever!). Those users later want to make modifications, and now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... >> >> So don't just promote to people "hey come and play with this cool toy of ours (Pharo)." >> Instead give them a toy they *already-want* (Markdown editor) and then when they want to change the batteries, they *need* to use our special screwdriver (Pharo). > > +1! > >> >> cheers -ben >> >> >> > Sure, maybe we were first with Pillar, but for me, lots of programming is in >> > other languages, and I use Smalltalk where I can, and a hybrid of multiple >> > languages and projects is often the reality - so a lowest common denominator >> > of Markdown is just easier. The fact that we are quite close to what our >> > colleagues in other languages use (regardless of what Python has chosen), is >> > quite interesting. >> >> This helps building "bridges" with other communities. >> >> >> >> >> >> >> The language as a means of exchange is always the lowest common denominator. >> As long as it's "efficient enough" then I vote to use what other >> communities use. >> >> > That said, if the community wants to stick to its gunâs thats fine - I will >> > probably still investigate how to use Commonmark for myself, and will still >> > contribute to Pillar docs where I can (and curse history) - but I think we >> > are long better off trying to join emerging standards where we can >> > particularly if they arenât our core language thing. And it just makes it >> > less frictionless for ourselves and newcomers. >> >> The "Not Invented Here" syndrome is strong among Smalltalkers, it's >> important to be aware of this bias and think more than once whether >> eating our own dogfood adds value to the core of what Pharo brings. >> >> I think we missed some good years fighting with our own SCM and in the >> end git (or any other file based SCM) prevailed, even when it has >> limitations. >> >> Pareto (80-20) for everything non-core business should be a guide. >> >> > Of course, if we were to move, we would need to translate a lot of quality >> > docs to a new format - but I would be up for contributing to that if that >> > was a deciding factor. >> >> There are some Markdown exporters AFAIK, or it could be written. >> >> >> Esteban A. Maringolo

Aug. 16, 2017