- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Zinc redirect bug?

by Sven Van Caekenberghe

Hi Aliaksei, This is an interesting problem, thanks for reporting it. I can reproduce the problem. If you inspect 'ZnLogEvent announcer' before doing the request, you can see that ZnClient does seem to do the same as 'curl -vOL https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib'. It follows one redirect, to the correct host and URL. One difference that I see that might lead to the 403 Forbidden is that Zn has a slight difference in the redirect URL being followed. Curl seems to follow /86/866a31722e3a9ea19c2bc4eeed2e1e69f7339ddd460500f2a33b4c9d041ef9b4?__gda__=exp=1500058371~hmac=820d22695ef0a821abc7e6eb7be6749ad43e8e0f74ba4b103476aa1b3663b381&response-content-disposition=attachment%3Bfilename%3D%22libMoz2D.dylib%22&response-content-type=application%2Fx-www-form-urlencoded&requestInfo=U2FsdGVkX19XiffCdVJdoADmObVHKjU4Wla5_WKFKHoNAvXQw8ponQIqWBsRUfNNDaULVXlXwB22y7xy0ls3DGkl700_9RxT-HtU92OHYdgKzSq9a6A7p5NIoMi4avCjPk_UCnVbt5U4_nxvkmKtuA While Zn turns this (parses the URL and then renders it again) into /86/866a31722e3a9ea19c2bc4eeed2e1e69f7339ddd460500f2a33b4c9d041ef9b4?response-content-type=application/x-www-form-urlencoded&response-content-disposition=attachment;filename%3D%22libMoz2D.dylib%22&requestInfo=U2FsdGVkX19XiffCdVJdoADmObVHKjU4Wla5_WKFKHoNAvXQw8ponQIqWBsRUfNNDaULVXlXwB22y7xy0ls3DGkl700_9RxT-HtU92OHYdgKzSq9a6A7p5NIoMi4avCjPk_UCnVbt5U4_nxvkmKtuA&__gda__=exp%3D1500058371~hmac%3D820d22695ef0a821abc7e6eb7be6749ad43e8e0f74ba4b103476aa1b3663b381 The difference is in the encoding of the __gda__ query parameter value. That contains = characters. These get escaped by Zn (the %3D) but are left untouched by curl. Maybe the server does not like that. I have to look deeper into the spec to figure out if this is a bug or not. Since query parameters look like key=value it seems odd to allow = in the value part. Another possible issue might be the order of query parameters that got changed. I'll come back to you if I find out more. Sven > On 14 Jul 2017, at 13:02, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hello, > > I am trying to download a file from bintray with the help of ZnClient. > I'm doing the following: > > ZnClient new > systemPolicy; > url: 'https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib'; > get; > yourself > > which results in Error 403. > > At the same time wget works as expected: > > wget https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib > > Trying to open this url in a browser works too. > > I tried to find out what may cause the error and it looks like it is something related to redirects because request and response headers look good... > > Thanks, > Alex

July 14, 2017

remote logging tool?

by Mariano Martinez Peck

Guys, I was wondering if there is already a wrapper to any of the typical loggers like Loggly, logentries, sumologic , papertrail, etc... thanks, -- Mariano http://marianopeck.wordpress.com

July 14, 2017

Re: [Pharo-dev] Zinc redirect bug?

by Tim Mackinnon

Iâm not sure if this is related - but the Pharo6 image is missing a ZnConstant initialise, and I recall redirect was one of the error codes missing. Possibly re-initialising ZnConstants might fix your problem? Tim > On 14 Jul 2017, at 12:02, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hello, > > I am trying to download a file from bintray with the help of ZnClient. > I'm doing the following: > > ZnClient new > systemPolicy; > url: 'https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib <https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib>'; > get; > yourself > > which results in Error 403. > > At the same time wget works as expected: > > wget https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib <https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib> > > Trying to open this url in a browser works too. > > I tried to find out what may cause the error and it looks like it is something related to redirects because request and response headers look good... > > Thanks, > Alex

July 14, 2017

Zinc redirect bug?

by Aliaksei Syrel

Hello, I am trying to download a file from *bintray* with the help of ZnClient. I'm doing the following: ZnClient new systemPolicy; url: ' https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib'; get; yourself which results in Error 403. At the same time wget works as expected: wget https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib Trying to open this url in a browser works too. I tried to find out what may cause the error and it looks like it is something related to redirects because request and response headers look good... Thanks, Alex

July 14, 2017

Re: [Pharo-dev] Pharo Launcher

by Esteban Lorenzano

> On 13 Jul 2017, at 02:41, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Stephane Ducasse-3 wrote >> where can I find the pharo launcher for the latest version of Pharo? > > Yes, it seems like the CI has been failing for weeks, or am I missing > something? Christophe was working on a new version. No idea whatâs the status but it should to be ready soon. Esteban > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-Launcher-tp4952930p4954660.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 14, 2017

Re: [Pharo-dev] Loading GitHub repositories in Pharo 4

by Sven Van Caekenberghe

> On 13 Jul 2017, at 15:00, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 13/07/2017 Ã 11:34, Sven Van Caekenberghe a Ã©crit : >>> On 13 Jul 2017, at 11:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi, >>> >>> Like others I seem to have trouble loading GitHub repositories, in Pharo 4 in my case. >>> >>> Basically, the following fails: >>> >>> Metacello new >>> baseline: 'P3'; >>> repository: 'github://svenvc/P3'; >>> load. >>> >>> But it also fails as dependency when specified like this: >>> >>> baseline: 'P3' with: [ >>> spec repository: 'github://svenvc/P3' ]; >>> >>> The problem seems to be related to the version info and meta data. (This project was created with Iceberg). >>> >>> MCFileTreeStCypressReader>>#loadVersionInfo >>> self hasMonticelloMetadata >>> ifTrue: [ ^ info := self extractInfoFrom: (self parseMember: 'version') ]. >>> ... >>> >>> The test #hasMonticelloMetadata succeeds, but 'version' is not found in /Users/sven/Tmp/pharo4/github-cache/svenvc/P3/master/svenvc-P3-6897866/BaselineOfP3.package/monticello.meta/version >>> >>> In the above method, there seems to be code to handle missing meta data, but it is not reached. >>> >>> Is this supposed to work ? >>> Is there a way around this ? >> I copied the following from a Pharo 6 image to the Pharo 4 image, Thierry's newer version: >> MCFileTreeAbstractReader>>#hasMonticelloMetadata >> ^ (self fileUtils >> filePathExists: 'version' >> relativeTo: >> (self fileUtils >> directoryFromPath: MCFileTreeStCypressWriter monticelloMetaDirName >> relativeTo: packageDirectory)) >> or: >> [ (self fileUtils >> filePathExists: 'version' >> relativeTo: packageDirectory) >> and: >> [ self fileUtils >> filePathExists: 'package' >> relativeTo: packageDirectory ] ] >> Which does the trick ! (It tests for 'version' explicitly). > > Yes, I added that to handle the switch to the Metadata-less format. > >> Is there a clean way to get this newer code in a 4.0 image ? > > Yes. Load FileTree from its repository. > >> Where does MonticelloFileTree-Core live when not integrated ? > > github, where else? > > (https://github.com/dalehenrich/filetree) Thanks for the reply. After some trial and error, the simplest way to get your patch in a Pharo 4 image is by doing Metacello new baseline: 'FileTree'; repository: 'github://dalehenrich/filetree:pharo4.0/repository'; load. After that, I can do meta-data-less code loading. > Regards, > > Thierry > >>> Thx, >>> >>> Sven

July 13, 2017

Re: [Pharo-dev] Loading GitHub repositories in Pharo 4

by Thierry Goubier

Le 13/07/2017 Ã 11:34, Sven Van Caekenberghe a Ã©crit : > >> On 13 Jul 2017, at 11:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> Like others I seem to have trouble loading GitHub repositories, in Pharo 4 in my case. >> >> Basically, the following fails: >> >> Metacello new >> baseline: 'P3'; >> repository: 'github://svenvc/P3'; >> load. >> >> But it also fails as dependency when specified like this: >> >> baseline: 'P3' with: [ >> spec repository: 'github://svenvc/P3' ]; >> >> The problem seems to be related to the version info and meta data. (This project was created with Iceberg). >> >> MCFileTreeStCypressReader>>#loadVersionInfo >> self hasMonticelloMetadata >> ifTrue: [ ^ info := self extractInfoFrom: (self parseMember: 'version') ]. >> ... >> >> The test #hasMonticelloMetadata succeeds, but 'version' is not found in /Users/sven/Tmp/pharo4/github-cache/svenvc/P3/master/svenvc-P3-6897866/BaselineOfP3.package/monticello.meta/version >> >> In the above method, there seems to be code to handle missing meta data, but it is not reached. >> >> Is this supposed to work ? >> Is there a way around this ? > > I copied the following from a Pharo 6 image to the Pharo 4 image, Thierry's newer version: > > MCFileTreeAbstractReader>>#hasMonticelloMetadata > ^ (self fileUtils > filePathExists: 'version' > relativeTo: > (self fileUtils > directoryFromPath: MCFileTreeStCypressWriter monticelloMetaDirName > relativeTo: packageDirectory)) > or: > [ (self fileUtils > filePathExists: 'version' > relativeTo: packageDirectory) > and: > [ self fileUtils > filePathExists: 'package' > relativeTo: packageDirectory ] ] > > Which does the trick ! (It tests for 'version' explicitly). Yes, I added that to handle the switch to the Metadata-less format. > Is there a clean way to get this newer code in a 4.0 image ? Yes. Load FileTree from its repository. > Where does MonticelloFileTree-Core live when not integrated ? github, where else? (https://github.com/dalehenrich/filetree) Regards, Thierry >> Thx, >> >> Sven > > >

July 13, 2017

Re: [Pharo-dev] Loading GitHub repositories in Pharo 4

by Sven Van Caekenberghe

> On 13 Jul 2017, at 11:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Like others I seem to have trouble loading GitHub repositories, in Pharo 4 in my case. > > Basically, the following fails: > > Metacello new > baseline: 'P3'; > repository: 'github://svenvc/P3'; > load. > > But it also fails as dependency when specified like this: > > baseline: 'P3' with: [ > spec repository: 'github://svenvc/P3' ]; > > The problem seems to be related to the version info and meta data. (This project was created with Iceberg). > > MCFileTreeStCypressReader>>#loadVersionInfo > self hasMonticelloMetadata > ifTrue: [ ^ info := self extractInfoFrom: (self parseMember: 'version') ]. > ... > > The test #hasMonticelloMetadata succeeds, but 'version' is not found in /Users/sven/Tmp/pharo4/github-cache/svenvc/P3/master/svenvc-P3-6897866/BaselineOfP3.package/monticello.meta/version > > In the above method, there seems to be code to handle missing meta data, but it is not reached. > > Is this supposed to work ? > Is there a way around this ? I copied the following from a Pharo 6 image to the Pharo 4 image, Thierry's newer version: MCFileTreeAbstractReader>>#hasMonticelloMetadata ^ (self fileUtils filePathExists: 'version' relativeTo: (self fileUtils directoryFromPath: MCFileTreeStCypressWriter monticelloMetaDirName relativeTo: packageDirectory)) or: [ (self fileUtils filePathExists: 'version' relativeTo: packageDirectory) and: [ self fileUtils filePathExists: 'package' relativeTo: packageDirectory ] ] Which does the trick ! (It tests for 'version' explicitly). Is there a clean way to get this newer code in a 4.0 image ? Where does MonticelloFileTree-Core live when not integrated ? > Thx, > > Sven

July 13, 2017

Loading GitHub repositories in Pharo 4

by Sven Van Caekenberghe

Hi, Like others I seem to have trouble loading GitHub repositories, in Pharo 4 in my case. Basically, the following fails: Metacello new baseline: 'P3'; repository: 'github://svenvc/P3'; load. But it also fails as dependency when specified like this: baseline: 'P3' with: [ spec repository: 'github://svenvc/P3' ]; The problem seems to be related to the version info and meta data. (This project was created with Iceberg). MCFileTreeStCypressReader>>#loadVersionInfo self hasMonticelloMetadata ifTrue: [ ^ info := self extractInfoFrom: (self parseMember: 'version') ]. ... The test #hasMonticelloMetadata succeeds, but 'version' is not found in /Users/sven/Tmp/pharo4/github-cache/svenvc/P3/master/svenvc-P3-6897866/BaselineOfP3.package/monticello.meta/version In the above method, there seems to be code to handle missing meta data, but it is not reached. Is this supposed to work ? Is there a way around this ? Thx, Sven

July 13, 2017

Re: [Pharo-dev] [OFFTOPIC] Update: Debris Publishing / Quuve Research & Portfolio Management Platform

by Mariano Martinez Peck

On Wed, Jul 12, 2017 at 5:22 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi mariano > > what kind of help do you want? > > Hi Stef, We are now at the stage where we are ready to solicit individual and institutional beta users to provide feedback on the features and help with quality control. And after several years of self-funding the project, we are also actively seeking funding in order to expand our development team. As you can hopefully tell from our videos, we built Quuve from the bottom-up, and our goal is to build the premiere investment management platform for investors of all sizes. Though Quuve is already quite powerful, indeed far more so than most tools on the market, we have a long-term vision we wish to see through, and this requires partnering with an institutional user and/or raising outside capital in the near future. Whether it be email blasts, reblogging about our software, or reaching out to technology investors you may know personally, we would appreciate any help you could provide that would assist us in finding these beta testers and institutional partners/investors. Thanks, > Stef > > > On Wed, Jul 12, 2017 at 9:53 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Hi all, > > > > A while back our team presented Quuve [1], a customizable investment > > management ecosystem for professional investors. We also discussed the > > technologies employed to build it [2] (it is developed on Pharo and > deployed > > on GemStone). We are reaching out again because we recently revamped our > > website [3] and created a number of promotional videos that demonstrate > > Quuve's power [4]. We would appreciate your help in marketing our wares! > > > > Quuve is the world's first fully integrated and customizable research and > > portfolio management platform. The system offers powerful features never > > before seen by the investment community and it empowers users to tailor > > tools in ways that accommodate their idiosyncratic investment style. In > the > > coming years, customization, data-inheritance, shared databases, > > machine-learning, and robo-trading will become standard among investors > of > > all sizes, and we expect Quuve will blaze the trail. > > > > If you have any questions about Quuve please let us know. > > > > [1] http://pharo.org/success/Quuve > > [2] http://forum.world.st/Fwd-Debris-Quuve-Technologies-used- > td4819786.html > > [3] http://www.debrispublishing.com/ > > [4] > > https://www.youtube.com/watch?list=PLfTMPTPc22sGNrm2rXt8kD-9 > iFTgqbAUG&v=zdm4CVse2Hc > > > > Thanks, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

July 13, 2017