September 2019 - Pharo-users

Re: [Pharo-users] Could not resolve ConfigurationOfJSON

by Offray Vladimir Luna CÃ¡rdenas

Hi Todd, Thanks for your interes in Grafoscopio. I would like to know more about your project and your feedback on how Grafoscopio suited your project (or not) is pretty valuable, so keep me posted. Grafoscopio should be working with Pharo 7, but I have been recently updating documentation that still doesn't end in the User Manual (but is already linked to SmalltalkHub and the English web page). Did you tried the procedure on: https://mutabit.com/repos.fossil/grafoscopio/doc/tip/readme.md.html#overvie… Let us know how the installation goes with those instructions. After that, the Panama Papers example should be available from the `Grafoscopio > Help & Docs > Dataviz` submenu, at the top bar (you may need to update Documentation and the Dataviz package before, from the `Grafoscopio > Update` menu). Cheers, Offray On 15/09/19 2:06 p.Â m., Todd Blanchard via Pharo-users wrote:

Sept. 16, 2019

Could not resolve ConfigurationOfJSON

by Todd Blanchard

Trying to check out Grafoscopio and I keep running into this error. Tried with Pharo 5 and 7. Any suggestions?

Sept. 15, 2019

Re: [Pharo-users] Code of Conduct

by John Pfersich

+100 /ââââââââââââââââââââ/ For encrypted mail use jgpfersich(a)protonmail.com Get a free account at ProtonMail.com Web: www.objectnets.net and www.objectnets.org > On Sep 12, 2019, at 10:13, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > There are some aspects of the "Covenant" that rub me up the wrong way. > I note that the only part of it where anyone actually promises to do > (or not do) anything is the "Pledge", which rather pointedly refrains > from treating people with different political viewpoints (like gun > ownership, or like TERFs who are silent about their opinions within > the group) well. It's about supporting diversity of *being*, not > diversity of *opinion*. > > There are other codes of conduct around which are framed in less > identitarian terms. And it is rather startling to find that one > is expected to be bound by a "Covenant" which is no Covenant (that > is, an *agreement*). A code of conduct can be imposed from the > top down; a covenant requires the consent of the governed. > > I am somewhat perturbed by the term "inclusive language" because > it is a shifting standard. I have frequently heard young women > addressing each other as "guys", yet have just recently watching > someone basically saying "I know it's gender neutral now and there > is no malice in it but it's exclusionary so it's really bad." > So if you say something like "hey guys" in a message, you have just > violated this covenant, and deserve to be thrown out. Or then > again, you may not have. Who decides? In a world where an > anti-racist black hero gets labelled a white supremacist, who decides? > > Here's another case. Many mailing lists or newsgroups have a policy > "no homework answers". If you tell someone off for violating that > policy, your mailing list or newsgroup is not welcoming and inclusive. > In another mailing list I am on, there is a clear and explicit "no HTML > postings" policy, for good topic-specific reason, and people are often > (politely) told off for violating it. As I read the Covenant, that's > not allowed. > > In a mailing list where you have no idea of my age, sex, body size, > gender orientation, etc, much of the Covenant is prima facie pointless. > > The Covenant goes way too far to be a mere "be nice to each other" guide. > > I have no intention of giving offence, and I am I not going to pull out > of the mailing list, but couldn't some less creepy code be adopted? > > > > > >> On Thu, 12 Sep 2019 at 08:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Sven Van Caekenberghe-2 wrote >> > https://www.contributor-covenant.org/version/1/4/code-of-conduct - which >> > is quite popular and generally accepted. >> >> Based on the reaction earlier in the thread, I was expecting something >> highly opinionated and polarizing, but it seems to boil down to: be >> professional and don't make it personal. While there are some categories of >> people mentioned, it doesn't seem to make a value judgement about them, but >> merely say that no one (including from those categories) will be harassed >> inside the Pharo community. Seems pretty reasonable, unless I'm missing >> something... >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>

Sept. 14, 2019

Re: [Pharo-users] uFFI ExternalAddress challenges

by TomaÅ¾ Turk

OK, I'm proceeding with the library that I mentioned (http://disphelper.sourceforge.net/) and I got nice results. Pablo's package goes directly into the core of OLE/COM automation and it would be too hard to for me to study it and continue with it at this stage. An example below loads Word for Windows, makes it visible, creates a new document and writes some text: | w | COMEngineAlpha initializeCOM . w := COMEngineAlpha createObjectByName: 'Word.Application'. COMEngineAlpha callObject: w setProperty: '.Visible = %b' withInteger: 1. COMEngineAlpha callObject: w method: '.Documents.Add'. COMEngineAlpha callObject: w method: '.Selection.TypeText(%S)' withString: 'This is a message to appear in Word document.'. COMEngineAlpha safeReleaseObject: w. COMEngineAlpha uninitializeCOM. However, I'd like to marshall a WideString through uFFI so that I won't loose UTF-8 support, of course the plain (String aString) signature doesn't work ("Cannot coerce arguments"). Is there anything I can do myself (i.e. without poking into Pharo virtual machine complexity) to solve this challenge? Best wishes, Tomaz ------ Original Message ------ From: "Torsten Bergmann" <astares(a)gmx.de> To: tomaz.turk(a)ef.uni-lj.si; pharo-users(a)lists.pharo.org Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Sent: 12. 09. 2019 12:07:34 Subject: Aw: Re: [Pharo-users] uFFI ExternalAddress challenges >From your snippets it looks like you want to do COM Automation on >Windows. > >Maybe you should have a look at: https://github.com/tesonep/pharo-com > >Bye >T. > >Gesendet: Donnerstag, 12. September 2019 um 11:08 Uhr >Von: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si> >An: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >Betreff: Re: [Pharo-users] uFFI ExternalAddress challenges > > We are interested in it >:) > > If I recall well Pablo got one version somewhere. > >Me too >:-) > Unfortunately, I only have time for 'weekend' projects, and any help >is appreciated >:-) > >Regarding the uFFI calls, is it possible to pass Win32WideString in a >similar fashion as a String - or where to look to implement that? > >Best wishes, >Tomaz

Sept. 13, 2019

Re: [Pharo-users] uFFI ExternalAddress challenges

by TomaÅ¾ Turk

> Maybe you should have a look at: https://github.com/tesonep/pharo-com Thanks for the link, I'll check it out - that's probably the work Steph has mentioned. Best wishes, Tomaz

Sept. 12, 2019

Re: [Pharo-users] Code of Conduct

by Richard O'Keefe

There are some aspects of the "Covenant" that rub me up the wrong way. I note that the only part of it where anyone actually promises to do (or not do) anything is the "Pledge", which rather pointedly refrains from treating people with different political viewpoints (like gun ownership, or like TERFs who are silent about their opinions within the group) well. It's about supporting diversity of *being*, not diversity of *opinion*. There are other codes of conduct around which are framed in less identitarian terms. And it is rather startling to find that one is expected to be bound by a "Covenant" which is no Covenant (that is, an *agreement*). A code of conduct can be imposed from the top down; a covenant requires the consent of the governed. I am somewhat perturbed by the term "inclusive language" because it is a shifting standard. I have frequently heard young women addressing each other as "guys", yet have just recently watching someone basically saying "I know it's gender neutral now and there is no malice in it but it's exclusionary so it's really bad." So if you say something like "hey guys" in a message, you have just violated this covenant, and deserve to be thrown out. Or then again, you may not have. Who decides? In a world where an anti-racist black hero gets labelled a white supremacist, who decides? Here's another case. Many mailing lists or newsgroups have a policy "no homework answers". If you tell someone off for violating that policy, your mailing list or newsgroup is not welcoming and inclusive. In another mailing list I am on, there is a clear and explicit "no HTML postings" policy, for good topic-specific reason, and people are often (politely) told off for violating it. As I read the Covenant, that's not allowed. In a mailing list where you have no idea of my age, sex, body size, gender orientation, etc, much of the Covenant is prima facie pointless. The Covenant goes way too far to be a mere "be nice to each other" guide. I have no intention of giving offence, and I am I not going to pull out of the mailing list, but couldn't some less creepy code be adopted? On Thu, 12 Sep 2019 at 08:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sven Van Caekenberghe-2 wrote > > https://www.contributor-covenant.org/version/1/4/code-of-conduct - which > > is quite popular and generally accepted. > > Based on the reaction earlier in the thread, I was expecting something > highly opinionated and polarizing, but it seems to boil down to: be > professional and don't make it personal. While there are some categories of > people mentioned, it doesn't seem to make a value judgement about them, but > merely say that no one (including from those categories) will be harassed > inside the Pharo community. Seems pretty reasonable, unless I'm missing > something... > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Sept. 12, 2019

Re: [Pharo-users] Stream >> <<

by Richard O'Keefe

> Why you changed `printSymbol: aClass name` > for `nextPutAll: aClass name`? Because there is no #printSymbol: anywhere in Pharo 7 or Pharo 8> , so I had to *guess* what it does, and the only reason I could see for using #printSymbol: instead of #print: is that class names are symbols and #print: will write a hash in front, and it seemed plausible that you would not want that hash. Accordingly I chose a well known, even standard, method that writes a class name with no extra decoration. > Now it outputs things incorrectly. You > should have changed it for `print: aClass name asSymbol` How is one supposed to *tell* what "correct" output is? If I wanted to write that code, I would be kind to my readers and make it *obvious* by doing stream nextPut; $#; nextPutAll: aClass name. I certainly would not go out of my way to confuse people by sending #asSymbol to something they already know is a Symbol. For what it's worth, I've attached my implementation. On Wed, 11 Sep 2019 at 21:46, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > On 11. 9. 2019 3:23, Richard O'Keefe wrote: > > It is good that you have a coherent idea of how << can work. > > After the changes sent by Sven, Pharo 8 seems to have the exactly same > idea. IMNSHO. > > > The question I was addressing is how << *DOES* work in Pharo. > > Having simple things working, if they are kept consistent, > > is indeed good. The problem is that in Pharo 7 they are NOT > > consistent, and << does NOT work consistently, because there > > are occasions when << does ^something nextPutAll: something else > > and nextPutAll: returns something else. > > Bug. '^' should not have been there. > > > I am grateful for the link to the changes to Pharo 8. > > That's a massive simplification and improvement. > > There is some way to go yet. > > Actually, from my PoV, just the fix I posted. The rest seems correct. > > > The very first thing that should be done is to write down > > what the *semantics* of #<< is supposed to be, and then to > > ensure it is implemented that way. > > > Let's look at the chunk example. > > > > exportTraitDefinitionOf: aClass on: aStream > > "Chunk format." > > aStream > > nextPutAll: 'Trait named: '; nextPutAll: aClass name; cr; > > The devil is in the details. Why you changed `printSymbol: aClass name` > for `nextPutAll: aClass name`? Now it outputs things incorrectly. You > should have changed it for `print: aClass name asSymbol` > > And this is precisely that distinction between low-level nextPutAll: and > high-level write: / << / print:. > > > tab; nextPutAll: 'package: '; print: aClass category; nextPutAll: > > '!!'; cr. > > aClass comment isEmpty ifFalse: [ > > aStream > > nextPutAll: '!!'; print: aClass; nextPutAll: 'commentStamp!!'; cr; > > nextPutAll: aClass category withDelimiter: $!; nextPutAll: '!!'; > cr]. > > aStream cr. > > > > With the exception of #nextPutAll:withDelimiter:, this is completely > > standard and portable. If I am willing to do something nonstandard, > > > > aStream format: 'Trait named: {s}{n}{t}package: {p}{n}' > > with: aClass name with: aClass category. > > aClass comment isEmpty ifFalse: [ > > aStream format: '!!{p} commentStamp!!{n}{D$!}!!{n}' > > with: aClass with: aClass comment]. > > aClass format: '{n}. > > > > #write: really does not seem to be any improvement over #nextPutAll:. > > Will post. > > > For what it's worth, GNU Smalltalk also has #<<, which it defines > > to be equivalent to #displayOn:, if memory serves me correctly. > > It has never been clear to me what the use case for #write: is. > > In Pharo 7, for streams it is the same as #putOn: except for the > > result. Neither of them is in any interesting way "higher > > level" than #nextPut: or #nextPutAll:, merely less informative. > > >

Sept. 12, 2019

Re: [Pharo-users] uFFI ExternalAddress challenges

by Ben Coman

On Thu, 12 Sep 2019 at 18:08, Torsten Bergmann <astares(a)gmx.de> wrote: > From your snippets it looks like you want to do COM Automation on Windows. > > Maybe you should have a look at: https://github.com/tesonep/pharo-com > Does that by chance include an implementation of "MS-CFB" Microsoft Compound File Binary https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cfb/50708a6… I was wanting to write a utility to parse headers of MSG files saved from Outlook, to process a for a project email archive by bulk renaming each MSG file with its transmit-date & subject. cheers -ben

Sept. 12, 2019

Re: [Pharo-users] uFFI ExternalAddress challenges

by Torsten Bergmann

Sept. 12, 2019

Re: [Pharo-users] uFFI ExternalAddress challenges

by TomaÅ¾ Turk

> We are interested in it :) > If I recall well Pablo got one version somewhere. Me too :-) Unfortunately, I only have time for 'weekend' projects, and any help is appreciated :-) Regarding the uFFI calls, is it possible to pass Win32WideString in a similar fashion as a String - or where to look to implement that? Best wishes, Tomaz

Sept. 12, 2019