- Pharo-users - lists.pharo.org

Fwd: [Pharo-users] Fwd: Debris' Quuve - Technologies used

by Cameron Sanders

Sure, I am happy to share. We are to the point that we need to get people interested in this platform; one thing we offer is a source license and therefore we need to document things that we have not yet documented. So please, fire away any questions. -Cam On Wed, Apr 15, 2015 at 5:59 PM, Brad <bsselfridge(a)gmail.com> wrote: > I'd love to know more about your architecture. It seems like you've built > an architecture very similar to what I've dreamed of building. Is there any > possibility of asking questions or of you providing examples of some of the > features from time to time? > > Brad Selfridge > 913-269-2385 > > > On Apr 15, 2015, at 4:30 PM, Cameron Sanders via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > > > > <mime-attachment> >

April 16, 2015

Re: [Pharo-users] Fwd: Debris' Quuve - Technologies used

by Brad

I'd love to know more about your architecture. It seems like you've built an architecture very similar to what I've dreamed of building. Is there any possibility of asking questions or of you providing examples of some of the features from time to time? Brad Selfridge 913-269-2385 > On Apr 15, 2015, at 4:30 PM, Cameron Sanders via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > <mime-attachment>

April 15, 2015

Re: [Pharo-users] Fwd: Debris' Quuve - Technologies used

by Luc Fabresse

Hi, Thanks for this email. It is really nice to read that all these frameworks are used in yet another successful commercial app such as Quuve. Best, #Luc 2015-04-15 23:30 GMT+02:00 Cameron Sanders via Pharo-users < pharo-users(a)lists.pharo.org>: > > > ---------- Message transfÃ©rÃ© ---------- > From: Cameron Sanders <camsanders(a)aol.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Date: Wed, 15 Apr 2015 17:30:24 -0400 > Subject: Fwd: Debris' Quuve - Technologies used > Several people inquired as to how Quuve was built. Mariano wrote up a nice > description of the various tools that were used to build Quuve -- see > below. Note also that DebrisPublishing.com website is now up; we are still > working on videos, but the site is very lean at present. > > -Cam > > Quuve Technologies Used > > Quuve has been and still is developed with Pharo. We try to use the most > up to date stable version of Pharo. Quuve is deployed in GemStone. > > Package dependencies are managed via Metacello. Not only do we have many > dependencies but also multiple Smalltalk environments: Pharo and GemStone. > We also use Metacello to correctly load the needed packages and versions > for each of the platforms. > > We use Seaside as our web framework and Twitter Bootstrap for Seaside for > the layout and design of the app. While some parts are still using the > full-request approach, most of the app is done with AJAX and only > refreshing the needed part of the screen. > > We use JQuery a lot and some external JS libraries such a DataTables (for > our table/reports), floatThead, HighCharts (for making charts), TinyMCE (to > edit notes and a few other things), etc. > > We have a full-featured CRUD system based on Magritte. Actually, we have > extended Magritte so much that all our descriptions and components are > actually subclasses of the original Magritte classes. We have our own > descriptions, components, report column classes, mementos, table layouts, > etc. All our framework is Twitter Bootstrap integrated, fully AJAX and with > lots of rich features. We can make a full CRUD report/form out of Magritte > descriptions in no time. > > For persistency we have a library/layer which gives a unified way of > saving and querying objects using a Glorp-like interface; it differs in > that the where clauses are straight Smalltalk blocks. So far, when we work > on Pharo we use Fuel as the "database", while for production we use > GemStone. We have developed some compatibility packages so that same code > would work in both Smalltalks in the way we expect. Quuve briefly used > Oracleâs relational DB for persistence of its securities DB, connecting to > it via the Glorp toolkit; because many mature financial DBâs are delivered > in relational form, we may need to do so more extensively in the future. > Although the need for this may subside as more data becomes available over > REST-server interfaces. > > We use NeoCSV for parsing CSV, XMLParser, Zinc-REST and STON for providing > REST web services, and SIXX for moving data between Pharo and GemStone. > > As to the web server, in Pharo we use Zinc, and in GemStone we use nginx + > FastCGI. Quuve clients could be for example, an individual or a large > advisory firm. In each case, Quuve is deployed as a "site/instance" for > each customer. Each site is a fully isolated and secured instance of Quuve. > > Quuve is hosted in a cloud virtual hosting which allows us to scale as > much as we need and we can have as many nodes as required. The operating > system is CentOS Linux. We correctly perform backups, cleanings and > maintenance of our sites. We have scripts to automatically create new sites > very easily. > > >

April 15, 2015

Fwd: Debris' Quuve - Technologies used

by Cameron Sanders

Several people inquired as to how Quuve was built. Mariano wrote up a nice description of the various tools that were used to build Quuve -- see below. Note also that DebrisPublishing.com website is now up; we are still working on videos, but the site is very lean at present. -Cam Quuve Technologies Used Quuve has been and still is developed with Pharo. We try to use the most up to date stable version of Pharo. Quuve is deployed in GemStone. Package dependencies are managed via Metacello. Not only do we have many dependencies but also multiple Smalltalk environments: Pharo and GemStone. We also use Metacello to correctly load the needed packages and versions for each of the platforms. We use Seaside as our web framework and Twitter Bootstrap for Seaside for the layout and design of the app. While some parts are still using the full-request approach, most of the app is done with AJAX and only refreshing the needed part of the screen. We use JQuery a lot and some external JS libraries such a DataTables (for our table/reports), floatThead, HighCharts (for making charts), TinyMCE (to edit notes and a few other things), etc. We have a full-featured CRUD system based on Magritte. Actually, we have extended Magritte so much that all our descriptions and components are actually subclasses of the original Magritte classes. We have our own descriptions, components, report column classes, mementos, table layouts, etc. All our framework is Twitter Bootstrap integrated, fully AJAX and with lots of rich features. We can make a full CRUD report/form out of Magritte descriptions in no time. For persistency we have a library/layer which gives a unified way of saving and querying objects using a Glorp-like interface; it differs in that the where clauses are straight Smalltalk blocks. So far, when we work on Pharo we use Fuel as the "database", while for production we use GemStone. We have developed some compatibility packages so that same code would work in both Smalltalks in the way we expect. Quuve briefly used Oracleâs relational DB for persistence of its securities DB, connecting to it via the Glorp toolkit; because many mature financial DBâs are delivered in relational form, we may need to do so more extensively in the future. Although the need for this may subside as more data becomes available over REST-server interfaces. We use NeoCSV for parsing CSV, XMLParser, Zinc-REST and STON for providing REST web services, and SIXX for moving data between Pharo and GemStone. As to the web server, in Pharo we use Zinc, and in GemStone we use nginx + FastCGI. Quuve clients could be for example, an individual or a large advisory firm. In each case, Quuve is deployed as a "site/instance" for each customer. Each site is a fully isolated and secured instance of Quuve. Quuve is hosted in a cloud virtual hosting which allows us to scale as much as we need and we can have as many nodes as required. The operating system is CentOS Linux. We correctly perform backups, cleanings and maintenance of our sites. We have scripts to automatically create new sites very easily.

April 15, 2015

Class comments rendered in Nautilus (through Pillar)

by Damien Cassou

Hi, Kasper Ãsterbye has just finished a proof-of-concept that renders Pillar text inside a class comment pane. >From the view, the developer can press $ (dollar) to edit the document in Pillar. Best regards, -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 15, 2015

Re: [Pharo-users] Roasal: Putting a white background instead of a transparent one in word clouds

by Alexandre Bergel

Thanks Peter! Alexandre > On Apr 13, 2015, at 1:08 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > I think there is a bug in the exporter, because the canvas has a color (which is white and _not_ transparent). > Normally you can set the color of the of the canvas (view canvas color: Color purple), but the default exporter (I assume you are exporting it via GT-inspector) is ignoring it. > There is however second exporter which you can use > > ~~~~~~~~~~~~~~~~~~~~~ > |v fileName| > v := RTView new. > v canvas color: Color purple. > v addAll: (RTEllipse new color: Color black; size: 30; elementsOn: (1 to: 10)). > RTCircleLayout on: v elements. > > fileName := UITheme builder > fileSave: 'Enter the PNG file name' > extensions: #('png') > path: nil. > "fileName := '/tmp/test.png' asFileReference." > fileName notNil ifTrue: [ > (DCTRCanvasExporter canvas: v canvas) > format: #png; > fileName: fileName fullName; > export ]. > > v > ~~~~~~~~~~~~~~~~~~~~~~~ > > You could also add the export code (with minor modification) to GLMRoassal2Presentation>>defaultActions but there seems to be some kind of bug that clears the content of the playground when executed from GLM, which is a big wtf, but maybe that's just my mixed up configuration. > > Peter > > > On Mon, Apr 13, 2015 at 5:17 PM, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > Hi, > > I have finally finished the first part of my visualization project of political discourses on Twitter. You can see the details here: > > http://mutabit.com/offray/static/blog/output/posts/visualizing-politiciansp… > > (As you can see Pharo was not used to extract the data, just to scrap it, structure it and visualize it). > > The politicians tag cloud look nice if the background is white, because the png background is transparent, but if you share it on Twitter, the black background makes the tag cloud invisible. I could use image editing programs to change the background from transparent to white, but I would like to know if there is a way to make that change inside Pharo/Roasal. > > Thanks for all your support in making this ideas possible. > > Cheers, > > Offray > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 15, 2015

Re: [Pharo-users] builder pattern

by Nicolai Hess

Hi Peter, 2015-04-09 21:20 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Is there some common / best way for coding builders? > > Two ways that I see are: > > a) using a block - I've seen this in menus and some other, however in my > case I need to add an extra parameter as label > > "variant with two params" > aForm addDropList: 'Type' with: [ :dropList | > dropList > items: #(input #output); > " ... ". > ]. > > "variant with one method param and value holder" > aForm addDropList: [ :labelHolder :dropList | > labelHolder value: 'Type'. > dropList > items: #(input #output); > " ... ". > ]. > > b) using return value - no blocks, no extra code > (aForm addDropList: 'Type') > items: #(input #output); > " ... ". > > I would use the second variant as it looks much cleaner, however > considering how widespread is the use of the first variant I think I must > be missing something. > Can you give an example, where the first variant is used. I don't really understand the use of the valueHolder in the second example. Wouldn't it be cleaner to define a DropList class /model that has methods for setting the label and items list? aForm addDropList:[:dropListMode | dropListModel setLabel:'...'. dropListModel setItems:{ .... } ] > > Thanks, > Peter >

April 15, 2015

Re: [Pharo-users] Zinc, servicing a full website

by Sven Van Caekenberghe

Hi Leo, > On 14 Apr 2015, at 14:28, Leo Paniceres <lpaniceres(a)gmail.com> wrote: > > Hi Sven, > > Thanks very much for your excellent Zinc package. > > Excuse me for contacting to your email, I couldnât find the official support email list. I much prefer answering question on the pharo-users ML, in CC. > My problem is that I could not find a way to solve simultaneously file servicing and services. > > I have a small app that responds to a request via a GET, and I also need to include in the response a lot of static files in a directory. > > How can I integrate two delegates? > > (ZnStaticFileServerDelegate and ZnDefaultServerDelegate) This is from an older answer, it should be applicable: Multiple handlers can be combined in one server. For example, http://zn.stfx.eu serves static content and serves all Zinc demos, with the following config (part of the startup script): | id logFile staticFileServerDelegate | id := 1. logFile := 'transcript.{1}.log' format: { id }. (NonInteractiveTranscript onFileNamed: logFile) install. (ZnServer defaultOn: 8080 + id) logToTranscript; route: 'r', id printString; start. (staticFileServerDelegate := ZnStaticFileServerDelegate new) prefixFromString: 'zn'; directory: '/home/ubuntu/zn' asFileReference. ZnServer default delegate prefixMap at: 'zn' put: [ :request | staticFileServerDelegate handleRequest: request ]; at: 'redirect-to-zn' put: [ :request | ZnResponse redirect: '/zn/index.html' ]; at: '/' put: 'redirect-to-zn'. HTH, Sven > -- > > Afectuosamenteâ desde Argentinaâ, (de corazÃ³n por mas que lo tenga automatico) > Leo

April 14, 2015

Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection

by stepharo

+1 Stef Le 14/4/15 17:02, Sven Van Caekenberghe a Ã©crit : >> On 14 Apr 2015, at 16:46, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. It was kept small and independent. >> Does that mean that I probably shouldn't touch it? Because when I wanted to use DDL I ran into a problem that once I add something to the list, I can no longer access the Links. LinkedList has "firstLink/lastLink", but this is missing in DoubleLinkedList -- is this design decision (to keep it small), or nobody needed it until now? > Both ;-) > >> Peter > Please make an issue with the API that you think should be added, and then we can have a look for Pharo 5. > > Sven > > >

April 14, 2015

Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection

by stepharo

I think that LinkedList should be a private class nobody should use :). Better use DoubleLinkedList which should be packaged with extended collection. Le 14/4/15 17:07, Henrik Johansen a Ã©crit : >> On 14 Apr 2015, at 2:09 , Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 14 Apr 2015, at 14:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Peter, >>> >>>> On 14 Apr 2015, at 13:52, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>> >>>> I was surprised to learn that DoubleLinkedList is descendant of Object, while LinkedList is descendant of SequencableCollection. Is there a particular reason behind this? Are they really so conceptually different that DLL is not even considered a collection? >>>> >>>> Thanks, >>>> Peter >>> DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. It was kept small and independent. >>> >>> Inheriting from [Sequenceable]Collection is a larger responsibility, entails more requirements. >>> >>> I would not be against this, although I am not 100% sure it is easy (some methods return the link nodes, not the elements, a distinction unknown to collections in general - LinkedList is a bit ugly in this respect too). In any case, it would have to be supported by enough tests. It could be a nice project for Pharo 5. >> One problem with LinkedList is that it is used by the scheduler and carefully written to be intererrupt-check free in some (undocumented) casesâ¦ in the past >> this has already lead to very bad side-effects when people wanted to improve it or change it. >> >> Marcus > IIRC, #removeLink:ifAbsent: is the only method (... that we've noticed) that needs to be atomic for the scheduler to work.(in other words, it can end up trying to remove the same process from different threads at the same time) > The change was made during a sprint to allow adding arbitrary objects and create links on the fly (inspired by Ruby, or so I was told), in the process the old remove:ifAbsent: turned into removeLink:ifAbsent, and a suspension point was introduced in the process, which meant, once in a blue moon, the scheduler would get stuck trying to remove a process that had already been removed. > > In other words; it's not a pleasant class to change. > > WRT being a subclass of SequenceableCollection; while technically true, that API is much wider than what you'd expect from a classic link list, and the inherited implementations mostly assume O(1) #at: performance. Very little is reimplemented, so most of it is rather slow if you try to actually use any of it: > ll := LinkedList withAll:#(a b c d e f g h i j k l m n o p q r s t u v x y z). > [ll allButFirst: 15] bench '150,365 per second' > > aa := Array withAll: #(a b c d e f g h i j k l m n o p q r s t u v x y z). > [aa allButFirst: 15] bench 10,055,029 per second > > Aside from pure bugs, there's also other oddities like the species being Array, but iteration methods reimplemented using self class. > > IOW: If you are looking for a LinkedList actually worth using, look elsewhere. > DoubleLinkedList may not be a Collection, but at least the API is small enough to grasp, and the parts that are there act as you expect them to. > > Cheers, > Henry >

April 14, 2015