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

Re: [Pharo-users] Zinc newbie question: How to get file metadata from Dropbox

by Sven Van Caekenberghe

> On 20 Jul 2017, at 19:57, Johannes Brauer <brauer(a)nordakademie.de> wrote: > > Hi! > > To download a file from Dropbox is easy: > > ZnClient new > https; host: 'content.dropboxapi.com'; > addPath: '2'; addPath: 'files'; addPath: 'download'; > headerAt: 'Authorization' put: > 'Bearer <my generated access token>'; > headerAt: 'Dropbox-API-Arg' put: '{"path": "/demo.txt"}' ;get. > > But I cannot figure out how to get file metadata > (https://www.dropbox.com/developers/documentation/http/documentation#files-g…) > > If I try the following > > (ZnClient new > https; host: 'api.dropboxapi.com'; > addPath: '2'; addPath: 'files'; addPath: 'get_metadata'; > headerAt: 'Authorization' put: > 'Bearer QfCCKhxI-HwAAAAAAAAGdeT916yqY4tkX3EN6EW2S3EMxYyv5Xky9LeCxuGi8_o7'; > headerAt: 'Content-Type' put: 'application/json'; > formAt: 'path' put: 'demo.txt'; post). > > I get the error message from Dropbox: > > Error in call to API function "files/get_metadata": Bad HTTP "Content-Type" header: "application/x-www-form-urlencoded". Expecting one of "application/json", "application/json; charset=utf-8", "text/plain; charset=dropbox-cors-hack". By using #formAt:put: you implicitly create a ZnApplicationFormUrlEncodedEntity instance, this is not what you want/need. This would POST proper JSON: ZnClient new https; host: 'api.dropboxapi.com'; addPath: '2'; addPath: 'files'; addPath: 'get_metadata'; headerAt: 'Authorization' put: 'Bearer QfCCKhxI-HwAAAAAAAAGdeT916yqY4tkX3EN6EW2S3EMxYyv5Xky9LeCxuGi8_o7'; entity: (ZnEntity with: (STONJSON toString: { #path->'demo.txt' } asDictionary) type: ZnMimeType applicationJson); post. Does that work ? > Probably I am using ZnClient wrongly. > > Johannes

July 20, 2017

Zinc newbie question: How to get file metadata from Dropbox

by Johannes Brauer

Hi! To download a file from Dropbox is easy: ZnClient new https; host: 'content.dropboxapi.com'; addPath: '2'; addPath: 'files'; addPath: 'download'; headerAt: 'Authorization' put: 'Bearer <my generated access token>'; headerAt: 'Dropbox-API-Arg' put: '{"path": "/demo.txt"}' ;get. But I cannot figure out how to get file metadata (https://www.dropbox.com/developers/documentation/http/documentation#files-g…) If I try the following (ZnClient new https; host: 'api.dropboxapi.com'; addPath: '2'; addPath: 'files'; addPath: 'get_metadata'; headerAt: 'Authorization' put: 'Bearer QfCCKhxI-HwAAAAAAAAGdeT916yqY4tkX3EN6EW2S3EMxYyv5Xky9LeCxuGi8_o7'; headerAt: 'Content-Type' put: 'application/json'; formAt: 'path' put: 'demo.txt'; post). I get the error message from Dropbox: Error in call to API function "files/get_metadata": Bad HTTP "Content-Type" header: "application/x-www-form-urlencoded". Expecting one of "application/json", "application/json; charset=utf-8", "text/plain; charset=dropbox-cors-hack". Probably I am using ZnClient wrongly. Johannes

July 20, 2017

UK Smalltalk User Group Meeting - Monday, 31st July

by Giovanni Corriga

The next meeting of the UK Smalltalk User Group Meeting will be on Monday, 31st July. We'll meet at a new venue The City Pride ( http://www.cityprideclerkenwell.co.uk/ ) at 7pm. If you'd like to join us, you can just show up at the pub. You can also sign up in advance at the meeting's Meetup page: https://www.meetup.com/UKSTUG/events/241876612/ . See you there!

July 20, 2017

Re: [Pharo-users] object serialization, STON & PharoJS

by Sven Van Caekenberghe

> On 20 Jul 2017, at 12:08, Diego Lont <diego.lont(a)delware.nl> wrote: > > Hi, > > What I remember of STON is that it simply puts out the entire tree. So it might include things you donât want (like thisContext), and also does not handle loops well. But that is from memory, I might be wrong there. Hmm, I think you are misinformed. STON was specifically designed to handle cycles and structure sharing in object graphs. STON won't interact with thisContext unless you make that part of your domain objects. A limitation of STON is that it won't handle blocks (though in some cases there are workarounds). It is possible to tune how your objects are serialised by STON with various mechanisms, including skipping certain instance variables. > For serialisation you could also look into the Magritte serialisation. It has several extenstions, among them one to output them in the JSon format. Disadvantage is that you have to describe your objects, but this is also helps you only send into the world the things you want. > > Regards, > Diego > >> On 16 Jul 2017, at 21:00, Siemen Baader <siemenbaader(a)gmail.com> wrote: >> >> Hi all, >> >> Iâm trying to transpile the STON class to JavaScript with PharoJS to use it in a client side web application. The goal is it to retrieve object(graphs) from the server and deserialize them in the frontend via xhr. >> >> But PharoJS doesn't support thisContext, I think that's a limitation of the JavaScript VM. PharoJS raises "PjJavascriptTranspilationError - thisContext not supported. Found in Collection >> #toBraceStack:". I tried to add the <pharoJsSkip> pragma to the method in the hope that it will not be needed for my uses, but no luck. >> >> Is the use of thisContext needed in STON, can I avoid it? I had hoped to use STON because it is simple and well documented and unlike JSON handles object graphs and classes. >> >> What are my options? >> >> Alternatively, what else could I use to serialize objects? I'm already using Voyage & Mongo on the backend which deal with JSON internally, and I think Moose also has a serialization component. Using a JS library in the frontend is also an option if there is a Pharo implementation for its format as well. >> >> Thanks, >> Siemen > >

July 20, 2017

Re: [Pharo-users] object serialization, STON & PharoJS

by Sven Van Caekenberghe

> On 16 Jul 2017, at 21:00, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > Hi all, > > Iâm trying to transpile the STON class to JavaScript with PharoJS to use it in a client side web application. The goal is it to retrieve object(graphs) from the server and deserialize them in the frontend via xhr. > > But PharoJS doesn't support thisContext, I think that's a limitation of the JavaScript VM. PharoJS raises "PjJavascriptTranspilationError - thisContext not supported. Found in Collection >> #toBraceStack:". I tried to add the <pharoJsSkip> pragma to the method in the hope that it will not be needed for my uses, but no luck. > > Is the use of thisContext needed in STON, can I avoid it? I had hoped to use STON because it is simple and well documented and unlike JSON handles object graphs and classes. > > What are my options? I don't know about PharoJS so I can't comment. The coolest option would be for someone to implement STON in JavaScript directly, it should be doable, but requires good JS skills. > Alternatively, what else could I use to serialize objects? I'm already using Voyage & Mongo on the backend which deal with JSON internally, and I think Moose also has a serialization component. Using a JS library in the frontend is also an option if there is a Pharo implementation for its format as well. > > Thanks, > Siemen

July 20, 2017

Re: [Pharo-users] object serialization, STON & PharoJS

by Diego Lont

Hi, What I remember of STON is that it simply puts out the entire tree. So it might include things you donât want (like thisContext), and also does not handle loops well. But that is from memory, I might be wrong there. For serialisation you could also look into the Magritte serialisation. It has several extenstions, among them one to output them in the JSon format. Disadvantage is that you have to describe your objects, but this is also helps you only send into the world the things you want. Regards, Diego > On 16 Jul 2017, at 21:00, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > Hi all, > > Iâm trying to transpile the STON class to JavaScript with PharoJS to use it in a client side web application. The goal is it to retrieve object(graphs) from the server and deserialize them in the frontend via xhr. > > But PharoJS doesn't support thisContext, I think that's a limitation of the JavaScript VM. PharoJS raises "PjJavascriptTranspilationError - thisContext not supported. Found in Collection >> #toBraceStack:". I tried to add the <pharoJsSkip> pragma to the method in the hope that it will not be needed for my uses, but no luck. > > Is the use of thisContext needed in STON, can I avoid it? I had hoped to use STON because it is simple and well documented and unlike JSON handles object graphs and classes. > > What are my options? > > Alternatively, what else could I use to serialize objects? I'm already using Voyage & Mongo on the backend which deal with JSON internally, and I think Moose also has a serialization component. Using a JS library in the frontend is also an option if there is a Pharo implementation for its format as well. > > Thanks, > Siemen

July 20, 2017

Re: [Pharo-users] Can anyone answer this?

by Tim Mackinnon

It would be nice if the JPMorgan folks could comment on this one (their system is now 20 years old I think, its huge, has had large numbers of people successfully working on it - concurrently) and I know they did leverage live coding ability particularly in error scenarios however there is a caveat - in that I think financial regulations curbed some of the live changeability to prevent any hint of fraud. Tim > On 20 Jul 2017, at 09:19, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I agree > > The stupidity of opposing live coding is that they only language that a computer can execute , machine code, is a live coding language. Live coding is extremely essential for machine coding and it does this through several way , using pointer registers to control flow of execution giving access to its registers that can even store execution instructions etc etc. To make matters worse for those opposing live coding , live coding is not only implemented at machine code level but also OS level. Memory mapped files are equivalent if not more powerful than Pharo images and there is also system exceptions to capture errors and lively replace code and of course shared memory which is crucial for the use of DLLs. There is also the ability of loading code as data in a place in memory and then mark that area executable and execute the code. > > It's the programming languages themselves that don't support live coding out of the box with the convenience of Pharo but because they are obliged to support OS features live coding is also something you can use with any programming language out there. > > Live coding is pretty much in the core of computer technology. It's pretty much obligatory for testing and debugging purposes which why also C debuggers com with live coding features. > > Version control systems and sandboxes environments are unrelated to live coding which is merely a way of coding and by no means against it with some exceptions. > > On Wed, 19 Jul 2017 at 22:11, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > I do not see why live coding programming languages could not manage > their source code in versioning control system. > To me, people opposing live coding and released/versioned software are > just **PLAIN** idiots. > Period. > You can have a live reflective system and still want to have a fully > reproducible built system. > This is what we do with Pharo. We manage everything with a version > control system and still Pharo > is fully dynamic. And No not everybody can commit and change Pharo. > > About large and complex systems, I heard that an insurance company has > 30 Millions lines Smalltalk application. > and this system is live and also versioned! Hopefully. > So do not lose your energy with idiots. > > Stef > > > > > On Wed, Jul 19, 2017 at 8:18 PM, jWarrior <dmacq(a)erols.com <mailto:dmacq@erols.com>> wrote: > > Well ..... > > > > I worked on JWARS for 13 years until the Navy killed it at the end of 2010, > > and I have never heard of Miles Fidelman. JWARS was run almost exclusively > > in SCIFs (secure facilities), and most of the users did not have access to > > the source code. So I do not know where Miles gets his information. > > > > JWARS had extensive version control. All new versions of the main config > > maps were tagged with extensive information about what was included. > > > > I agree with what Richard says below, "I suspect Miles doesn't really > > understand what a âlive coding environmentâ really means.", although I would > > phrase it less gently. > > > > > > > > -- > > View this message in context: http://forum.world.st/Can-anyone-answer-this-tp4955861p4955916.html <http://forum.world.st/Can-anyone-answer-this-tp4955861p4955916.html> > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

July 20, 2017

Re: [Pharo-users] Can anyone answer this?

by Dimitris Chloupis

I agree The stupidity of opposing live coding is that they only language that a computer can execute , machine code, is a live coding language. Live coding is extremely essential for machine coding and it does this through several way , using pointer registers to control flow of execution giving access to its registers that can even store execution instructions etc etc. To make matters worse for those opposing live coding , live coding is not only implemented at machine code level but also OS level. Memory mapped files are equivalent if not more powerful than Pharo images and there is also system exceptions to capture errors and lively replace code and of course shared memory which is crucial for the use of DLLs. There is also the ability of loading code as data in a place in memory and then mark that area executable and execute the code. It's the programming languages themselves that don't support live coding out of the box with the convenience of Pharo but because they are obliged to support OS features live coding is also something you can use with any programming language out there. Live coding is pretty much in the core of computer technology. It's pretty much obligatory for testing and debugging purposes which why also C debuggers com with live coding features. Version control systems and sandboxes environments are unrelated to live coding which is merely a way of coding and by no means against it with some exceptions. On Wed, 19 Jul 2017 at 22:11, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I do not see why live coding programming languages could not manage > their source code in versioning control system. > To me, people opposing live coding and released/versioned software are > just **PLAIN** idiots. > Period. > You can have a live reflective system and still want to have a fully > reproducible built system. > This is what we do with Pharo. We manage everything with a version > control system and still Pharo > is fully dynamic. And No not everybody can commit and change Pharo. > > About large and complex systems, I heard that an insurance company has > 30 Millions lines Smalltalk application. > and this system is live and also versioned! Hopefully. > So do not lose your energy with idiots. > > Stef > > > > > On Wed, Jul 19, 2017 at 8:18 PM, jWarrior <dmacq(a)erols.com> wrote: > > Well ..... > > > > I worked on JWARS for 13 years until the Navy killed it at the end of > 2010, > > and I have never heard of Miles Fidelman. JWARS was run almost > exclusively > > in SCIFs (secure facilities), and most of the users did not have access > to > > the source code. So I do not know where Miles gets his information. > > > > JWARS had extensive version control. All new versions of the main config > > maps were tagged with extensive information about what was included. > > > > I agree with what Richard says below, "I suspect Miles doesn't really > > understand what a âlive coding environmentâ really means.", although I > would > > phrase it less gently. > > > > > > > > -- > > View this message in context: > http://forum.world.st/Can-anyone-answer-this-tp4955861p4955916.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > >

July 20, 2017

Re: [Pharo-users] Why does debugger browse open on Object?

by Tim Mackinnon

It turns out it's trivial - just create a subclass of DebugAction (the create one has all the pieces you need). Not sure how you get an icon on the button (create doesn't either). Maybe I can propose it for 7. Possibly call it "browse receiver"? (A bit long though) Tim Sent from my iPhone > On 19 Jul 2017, at 19:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > >> On 19 Jul 2017, at 19:56, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> Hi Tim, all >> >> 2017-07-19 14:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: >>> Hi - I've always meant to ask this question as it often catches me out. >>> >>> When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use. >>> >>> It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand.... >>> >>> But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful. >> >> Yesterday I was going to ask about this behavior, which has been >> nagging me for some time. I feel better reading it isn't only me who's >> sensitive to this friction. >> >> I don't understand why it is like this, but I assume it is because of >> a common behavior of browsing the receiver object in the stack frame >> without considering particular cases like Object>>doesNotUnderstand: >> >> I'll be happy if you find a way to implement it, as a System Option or >> via a shortcut modifier. > > In fact, some years ago Camillo Bruni implemented a solution for this (it was opening the debugger in the place where the DNU was originated) but I think it was deactivated because people was not so happy. > Maybe now is time to retry ;) > > Esteban > >> >> Regards! >> >> Esteban A. Maringolo >> > >

July 19, 2017

Re: [Pharo-users] Can anyone answer this?

by Bob Hartwig

On Wed, Jul 19, 2017 at 9:47 AM, horrido <horrido.hobbies(a)gmail.com> wrote: > > 1) When everything is a work in progress, itâs impossible to manage a > project, maintain deployed code (âwhat version do you have, what did you > modify? clearly thatâs where the bug isâ), update things (interfaces > change, > updates overwrite local mods), etc. > > I've been working on a big production Smalltalk application (IBM Smalltalk / VisualAge) for a long time, and the approach we take is to use the development environment for R&D, and with select beta customers, and then periodically package a runtime when we want to release to the customer base. It gives the best of both worlds: a live development environment with the myriad debugging and productivity advantages that that brings, and a more conventional deployment model for the customers. > 2) The typical deployment model is to deploy a completely new virtual > machine & environment. For some things (e.g., servers), that works - and > seems to be the way of the world with containerization - but for other > things (e.g., desktop applications), deploying an entire new environment > for > every patch is just a bit match. > > Don't know why you'd need to deploy a completely new VM and environment with each release. When we give a customer an update, we give them a new packaged runtime image, which is a small fraction of the size of the VM and its supporting files. When we had a Smalltalk "fat client" (now our UI is RESTful web services and XHR-heavy web app), deploying the runtime image for each release worked well.

July 19, 2017