- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [OT] NO-SLQ vs RDBMS Re: FluidDB API for Pharo
by StÃ©phane Ducasse Sept. 25, 2010

Sept. 25, 2010

> > > > > You can find many topics about it in the net. > > Yes, but the net is full of idiots too. I mean...if I read the net then I should be programing in Java... > I want to hear if someone of you, someone I know, had real experience with both alternatives. And why you would choose one over the other one. > > In addition, if someone has experience with a real app using Seaside or something like that. you mean using seaside and NOSLQ db? > > > This topic is really overheated :) > > > yes, I know :) >

1 0

Re: [Pharo-project] FluidDB API for Pharo
by StÃ©phane Ducasse Sept. 25, 2010

Sept. 25, 2010

thanks jordi On Sep 25, 2010, at 8:25 PM, Jordi Delgado wrote: > oops! just fixed. Now you should be able to get it. Sorry. > > Bests, > > Jordi > > >> >> On 25 Sep 2010, at 10:22, Jordi Delgado wrote: >> >>> Hi >>> >>> I write just to let you know that we (the smalltalk.cat group) did an >>> API to interact with a nice no-SQL database called FluidDB. It has been >>> mainly the work of Sergio Garcia, but there is a little of some of us in the >>> tests and the code: >>> http://www.squeaksource.com/FluidDB.html >>> To see what this FluidDB is: >>> http://fluidinfo.com/ >>> >>> Bests, >>> >>> Jordi >> >> Sounds interesting, however the SqueakSource project has a 'Global: no access', so we can't see anything. >> >> Sven >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] After loading a package...all changes with "revision changed"
by Mariano Martinez Peck Sept. 25, 2010

Sept. 25, 2010

Hi. I am having a probem with Glorp and I really have no idea what can be. The problem is that I load the package Glorp and just after loading, I do a "changes" in the MC Browser and I see a lot of classes with a lot of changes and all of them like "revison changed". This is annoying since it doesn't let me easily see what I have really changed. To reproduce: - Load the package "Glorp" from http://www.squeaksource.com/SqueakDBX - Open a MC Browser, select Glorp package and press the "Changes" button agains the ss repo. And you will see :) Any help is really appreaciated. Thanks Mariano

1 0

[Pharo-project] FluidDB API for Pharo
by Jordi Delgado Sept. 25, 2010

Sept. 25, 2010

Hi I write just to let you know that we (the smalltalk.cat group) did an API to interact with a nice no-SQL database called FluidDB. It has been mainly the work of Sergio Garcia, but there is a little of some of us in the tests and the code: http://www.squeaksource.com/FluidDB.html To see what this FluidDB is: http://fluidinfo.com/ Bests, Jordi

2 2

[Pharo-project] squeaksource is down :(
by Mariano Martinez Peck Sept. 25, 2010

Sept. 25, 2010

thanks mariano

1 0

Re: [Pharo-project] Fame vs Magritte
by StÃ©phane Ducasse Sept. 25, 2010

Sept. 25, 2010

here is my summary fame is a minimal meta meta model ( 4 or 5 classes): we use it describe other model (such as Famix) based on fame you can load and save model. Magritte is a meta data driven framework. you describe specific entity and the tools interpret it. On Sep 25, 2010, at 11:24 AM, FranÃ§ois Tanguy wrote: > Hi, > > being a end user, I am bit confused with these 2 frameworks: Fame and Magritte. > There are both meta-meta-models. So what make them different from a conceptual point of view ? > > For my models, I would like to have the persistency for free (from Fame) and the UI edition and model validation for free (from Magritte). > > Today I must write two times the description of my language (one in Fame and one in Magritte), and it feels like I would need only one description. > > Any info on this would be appreciated. > > Thanks. > > Francois > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Fame vs Magritte
by FranÃ§ois Tanguy Sept. 25, 2010

Sept. 25, 2010

Hi, being a end user, I am bit confused with these 2 frameworks: Fame and Magritte. There are both meta-meta-models. So what make them different from a conceptual point of view ? For my models, I would like to have the persistency for free (from Fame) and the UI edition and model validation for free (from Magritte). Today I must write two times the description of my language (one in Fame and one in Magritte), and it feels like I would need only one description. Any info on this would be appreciated. Thanks. Francois

1 0

Re: [Pharo-project] Zinc HTTP Components
by Sven Van Caekenberghe Sept. 25, 2010

Sept. 25, 2010

Matt, On 24 Sep 2010, at 21:02, Matt Kennedy wrote: > Hi Sven, > > I am interested mostly in the client side right now and will take up your suggestion of implementing a new client within the Zn components. The client I started a couple days ago subclassed ProtocolClient and I can lift stuff I did from that client for a new Zn client. My current client had cookie handling, chunked encoding, and configurable automatic redirect handling. I myself am not so much interested in keep alive connection reuse, though it'd certainly have some use. My main goals for a client library are to support persistent client sessions, pluggable authentication, and easy header control, which are things I've found lacking when trying to implement some web APIs using HTTPSocket. Sounds really interesting, I am looking forward at seeing your code! Sven > I am on the Pharo-project list and squeak-dev currently. I'll make sure I'm on all the pharo lists so future discussions can happen openly there. > > Matt > > On Sep 24, 2010, at 1:47 PM, Sven Van Caekenberghe wrote: > >> Hi Matt, >> >> On 24 Sep 2010, at 18:01, Matt Kennedy wrote: >> >>> Hi, >>> >>> I wanted to write and thank you for the work you've done here with your library. I just recently started this week on working on a replacement for HTTPSocket because I wanted to implement OAuth for Pharo and HTTPSocket just doesn't cut it. You've got a nice bundle packaged up and are a lot farther along, so I'd much rather support your work. >>> >>> My question for you is how much of the client code from the Old collection of packages are you planning on refactoring into the New packages? I'd like to work on bringing over the session and cookie code and instance side methods of ZnHTTPClient over in order to support making multiple requests from a single client instance and work on an OAuth authenticator, which is what got me started on this road to begin with. >>> >>> Regards, >>> Matt Kennedy >> >> Thanks for your interest. I presume you have read the project's main page and getting started guide, especially the Status, Todo & Future sections. Those should answer most of your questions. >> >> Now, basic Cookie support should be a standalone class or two (ZnCookie, ZnCookieJar). The exesting ones are not that clean, if you know the subject, you could do that from scratch. This is not something that I would do first. >> >> Although the current (server side) authenticator is pluggable, it is hardwired for basic authentication. Obviously there are other authentication schemes. So authenticator should become a more intelligent object that does what ZnServer>>#authenticateRequest:do: now does. I could do the refactoring (server side) with an abstract superclass and basic authentication as concrete subclass. I don't know if server and client side are unifyable. >> >> If you are mostly interested in the client side, I would suggest that you try to write your own client, separate from the current one (ZnClient is only a very simple class side collection of utilities). One of the first things I wanted to do next was a client that reuses connections (as well as chunked and gzip encoded transfers). Reusing connections is actually a pretty special case when you keep on hitting one server very frequently, otherwise the reuse effort is not worth the trouble (re-establising connections) - that is what I found in other HTTP clients that I wrote. What do you think ? >> >> I am not familiar with OAuth, I just heard about it, something like that would be most interesting. But maybe this could be an add-on package, I don't known how elaborate it is ? >> >> BTW, are you on Pharo ? I would like to have discussions like this openly on the pharo dev list. >> >> Sven >

1 0

[Pharo-project] Smalltalk memoryHogs
by Igor Stasenko Sept. 25, 2010

Sept. 25, 2010

Just some thoughts... Magma registers own entities as a memory hog, using (Smalltalk memoryHogs add: ...) and then if error happens (because i experimenting with it), i have a reference handling, and i need to cast weird incarnations to get rid of it. What i thinking , that memoryHogs should be not just simple OrderedCollection, but WeakArray instead. Then it won't keep hanging references, and don't force to remove them manually. But the problem is, that its implementation: memoryHogs "Answer the list of objects to notify with #freeSomeSpace if memory gets full." ^ MemoryHogs ifNil: [MemoryHogs := OrderedCollection new] means that any user could send #add: or #remove: at any time. So, i can't replace OrderedCollection with just WeakArray, because it will break the users of this message. :( So, i think that memoryHogs should be deprecated and instead, and we should provide #registerMemoryHog: and #unregisterMemoryHog then we are free to use something else than OrderedCollection. -- Best regards, Igor Stasenko AKA sig.

1 0

Re: [Pharo-project] Webpage for research paper about Pharo?
by Marcus Denker Sept. 24, 2010

Sept. 24, 2010

On Sep 22, 2010, at 7:31 PM, Janko MivÅ¡ek wrote: > Why not rather all Smalltalk research page instead? Or website, like > http://research.world.st? > > I think our community is too small to divide it even further and > research is something which is by definition wide open. So, as we have > thanks to Mariano now all Smalltalk research mailing list, let we have > all Smalltalk research website too! But with that reasoning: Why have a pharo website at all? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 2