- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Ann] DragPanels: Floating palette windows with drag-and-drop in Morphic

by Hannes Hirzel

Thank you, Stephan, for providing a well worked out example continuing where Morphic tutorials normally end. This is a real need to unearth functions which have been there fore years but mostly unused. The two video clips document the use cases of the code nicely. A question not answered yet is: How do I export the panel with the cards as an SVG file? --Hannes -- View this message in context: http://forum.world.st/Ann-DragPanels-Floating-palette-windows-with-drag-and… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 29, 2015

Re: [Pharo-users] RAM-efficient alternative to ZnMultiPartFormDataEntity

by mikefilonov

Hi Sven, Thank you for a prompt reply. I have in mind something similar to the followin nginx plugin: http://www.grid.net.ru/nginx/upload.en.html We could dump entity body directly from socket stream to a file (buffered reader/writer) and add a header to Request so backend could just have a file name (or FileReference?) instead of a ByteArray. I think this could help lowering RAM requirements for web-services which accepts files. -- View this message in context: http://forum.world.st/RAM-efficient-alternative-to-ZnMultiPartFormDataEntit… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 29, 2015

Re: [Pharo-users] RAM-efficient alternative to ZnMultiPartFormDataEntity

by Sven Van Caekenberghe

Hi Mike, > On 29 Jun 2015, at 04:43, mikefilonov <mikefilonov(a)gmail.com> wrote: > > Hello, > > I'm searching for an alternative implementation of ZnMultiPartFormDataEntity > which dumps it's parts to Filesystem as files saving RAM. > > Is there such an addon or it should be developed? No, there is no such a thing, and it could be useful, although I am not sure what you have in mind exactly. Please propose something we can discuss. Sven > Thanks, > Mike > > > > -- > View this message in context: http://forum.world.st/RAM-efficient-alternative-to-ZnMultiPartFormDataEntit… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

June 29, 2015

RAM-efficient alternative to ZnMultiPartFormDataEntity

by mikefilonov

Hello, I'm searching for an alternative implementation of ZnMultiPartFormDataEntity which dumps it's parts to Filesystem as files saving RAM. Is there such an addon or it should be developed? Thanks, Mike -- View this message in context: http://forum.world.st/RAM-efficient-alternative-to-ZnMultiPartFormDataEntit… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 29, 2015

Re: [Pharo-users] RESTful API with Pharo with Gemstones

by HernÃ¡n Morales Durand

Sorry bad typing. I wonder if you have another version than the published in SmalltalkHub (using Swagger-Support-V12-SebastianHeidbrink.1 currently) If I evaluate: (SwaggerAPIReaderV12 on: 'http://petstore.swagger.io/v2/swagger.json') readSwaggerAPIListing inspect Then "apis" Collection I guess are not read, just "info" (a SwaggerAPISpecListingInfo). Is there something missing? Cheers, HernÃ¡n 2015-06-28 18:50 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Sebastian > > I wonder if you > > > 2015-06-25 14:51 GMT-03:00 Sebastian Heidbrink <sheidev(a)yahoo.de>: > >> Actually with the new version 2.0 I would also change my workflow. >> Version 1.2 had not online spec editor tooling support and this is why I >> let Gemstone describe my REST API and render the Swagger json specification. >> >> In Swagger 2.0 I would rather take the online spec editor define a >> swagger spec and take the resulting json file to generate ZincRESTCall >> subclasses. >> This way a client developer or user is able to define his or her needs. >> >> Whish I had more time right now. >> >> Sebastian >> >> >> >> Am 24.06.2015 um 01:14 schrieb itlists(a)schrievkrom.de: >> >>> We go a very similiar way as Sebastian - but with our company need NOT >>> to build a Smalltalk-only system, but also offer support for several >>> other developers/languages. >>> >>> We use >>> >>> * Zinc REST >>> >>> * Gemstone 3.2.6 >>> >>> We generate code to have: >>> >>> * Swagger-UI and Swagger-Core support (currently 1.2) >>> >>> Earlier the swagger stuff was also handled by Gemstone, but now we >>> create Gemstone-Code to write the Swagger-specs into the server >>> filesystem. >>> >>> Practically the swagger-core support has been working with C# (we had to >>> correct/change the template for source code generation). >>> >>> We see now the need to go to Swagger 2.0, to stay near the development >>> master stream. >>> >>> The whole system is working very stable - the only problem I have is a >>> 10 MB limit on the Gemstone socket system - here the Zinc HTTP System >>> subsystem must be changed to get rid of this problem. >>> >>> >>> Marten >>> >>> Am 23.06.2015 um 20:40 schrieb sergio_101: >>> >>>> I have been a project coming up that I really onlyneed a restful API >>>> on. >>>> >>>> The front end will be first built on a mobile device(iOS )then back on >>>> possibly android, with a very stripped down web application. >>>> >>>> i would like to use pharo/gemstones as the database. >>>> >>>> is there a project out there that allows for such restful API >>>> development in pharo land? This would be so fun! >>>> >>>> thanks >>>> >>> >>> >> >> >

June 28, 2015

Re: [Pharo-users] RESTful API with Pharo with Gemstones

by HernÃ¡n Morales Durand

Sebastian I wonder if you 2015-06-25 14:51 GMT-03:00 Sebastian Heidbrink <sheidev(a)yahoo.de>: > Actually with the new version 2.0 I would also change my workflow. > Version 1.2 had not online spec editor tooling support and this is why I > let Gemstone describe my REST API and render the Swagger json specification. > > In Swagger 2.0 I would rather take the online spec editor define a swagger > spec and take the resulting json file to generate ZincRESTCall subclasses. > This way a client developer or user is able to define his or her needs. > > Whish I had more time right now. > > Sebastian > > > > Am 24.06.2015 um 01:14 schrieb itlists(a)schrievkrom.de: > >> We go a very similiar way as Sebastian - but with our company need NOT >> to build a Smalltalk-only system, but also offer support for several >> other developers/languages. >> >> We use >> >> * Zinc REST >> >> * Gemstone 3.2.6 >> >> We generate code to have: >> >> * Swagger-UI and Swagger-Core support (currently 1.2) >> >> Earlier the swagger stuff was also handled by Gemstone, but now we >> create Gemstone-Code to write the Swagger-specs into the server >> filesystem. >> >> Practically the swagger-core support has been working with C# (we had to >> correct/change the template for source code generation). >> >> We see now the need to go to Swagger 2.0, to stay near the development >> master stream. >> >> The whole system is working very stable - the only problem I have is a >> 10 MB limit on the Gemstone socket system - here the Zinc HTTP System >> subsystem must be changed to get rid of this problem. >> >> >> Marten >> >> Am 23.06.2015 um 20:40 schrieb sergio_101: >> >>> I have been a project coming up that I really onlyneed a restful API on. >>> >>> The front end will be first built on a mobile device(iOS )then back on >>> possibly android, with a very stripped down web application. >>> >>> i would like to use pharo/gemstones as the database. >>> >>> is there a project out there that allows for such restful API >>> development in pharo land? This would be so fun! >>> >>> thanks >>> >> >> > >

June 28, 2015

Re: [Pharo-users] [Ann] DragPanels: Floating palette windows with drag-and-drop in Morphic

by Stephan Eggermont

On 28/06/15 20:22, Stephan Eggermont wrote: > On 28/06/15 17:10, stepharo wrote: >> Stefan >> >> It would be fun to see if you can implement the same in Bloc > > Where do I find some info on how to structure that in Bloc? > When should I subclass BlMorph and when BlView? It might be > a good case to explain some of the design trade-offs in Bloc > and compare them to Morphic. Oh, that Bloc documentation chapter has grown a lot since last time I looked at it :) Stephan

June 28, 2015

Re: [Pharo-users] [Ann] DragPanels: Floating palette windows with drag-and-drop in Morphic

by Stephan Eggermont

On 28/06/15 17:10, stepharo wrote: > Stefan > > It would be fun to see if you can implement the same in Bloc Where do I find some info on how to structure that in Bloc? When should I subclass BlMorph and when BlView? It might be a good case to explain some of the design trade-offs in Bloc and compare them to Morphic. Stephan

June 28, 2015

Re: [Pharo-users] how to get all the send to super?

by Nicolai Hess

2015-06-28 17:25 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > I would like to study the use of super. > Any idea how I can query them? > > Stef > > | rule result | rule := CodeSearchingRule new matcher: (RBParseTreeSearcher new matches: 'super' do: [ :node :answer | node ]; yourself); yourself. result := RBSmalllintChecker runRule: rule onEnvironment: RBBrowserEnvironment default. MessageBrowser browse: result result methods title:'super' autoSelect:'super'

June 28, 2015

Re: [Pharo-users] how to get all the send to super?

by Camille

> On 28 Jun 2015, at 17:25, stepharo <stepharo(a)free.fr> wrote: > > Hi > I would like to study the use of super. > Any idea how I can query them? Hi Stef, To get all methods that have a super send you can do: superSenders := CompiledMethod allInstances select: #sendsToSuper If you need more advanced search you can do it with RBParseTreeSearcher. For exemple to get each super message node: superSends := OrderedCollection new. searcher := RBParseTreeSearcher new matches: 'super ``@msg: ``@args' do: [ :node :ans | superSends add: node ]. superSenders do: [ :each | searcher executeTree: each ast ]. superSends Camille > > Stef >

June 28, 2015