> Just popping in to say that I've been using SIXX to transfer 39Mb of data (size in SIXX xml format) between Pharo and Gemstone without problems (other than Gemstone's temp memory size).
> I think it's definitely an option for an emergency export/import. > i have never messed with SIXX.. actually, i have no idea what it is.. > It's been quite some time since I've played with Pier, but wasn't there an export/import built-in? > there is an export built in, but i need the web interface to work with it.. and the web interface is broken.. -- ---- peace, sergio photographer, journalist, visionary http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by sergio_101-2
I had exactly this problem with Scheduler...
The way I cleared it off my system was like this: In a Workspace: TaskScheduler allInstances do: [ :each | each stop ]. Then I deleted the category and classes (or use Monticello to unload the package). However, there was still one method remaining. So, search for this method and delete it: DateAndTime >> now (It's in the Kernel-Chronology category, *Scheduler-override protocol) This should restore your system to normal. Hope this helps, and that it's not too late! Amir On Mon, 3 Jan 2011 10:47:04 -0500 sergio_101 <[hidden email]> wrote: > it's surprising easy to totally mess up a pier/seaside image.. i think > i find new ways every day.. > > i have a new image ready to go for my photography site. i am trying > desperately to release it today, and am having trouble.. > > in order to get it ready to save the image every half hour, i > installed scheduler > (http://squeaksource.com/@mlSPrDhf5NjYQ5So/UwX1Tlcu).. > > i set up an instance of scheduler, and it caused all sorts of > problems.. so i deleted the classes.. > > unfortunately, the problems are all still there. it appears that it's > still looking for the classes, and it keeps crashing with a system > error. i will try attaching a screen shot.. it's not a debug error, > but an actual system error.. > > i can't reinstall scheduler, because that error pops up again, and kills it.. > > if i could find whatever calls are being made to scheduler, i could > delete that, and that should work.. > > or, if i could somehow revert to the image before i added scheduler, > that would fix it too, but i can't figure out how to do that, either. > The backup images that pier was saving have the same problem.. > > any help would be greatly appreciated... seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Paul DeBruicker
> SystemNavigation default obsoleteClasses isEmpty
> ifFalse: [SystemNavigation default obsoleteClasses > do: [:each | [PointerFinder on: each] > on: Error > do: [:error | Transcript show: error; cr]]]. whoa! okay... this is finding EXACTLY the problems i am trying to fix.. once i find them (there are three) .. how do i go about deleting them?/ thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by AA-2
> In a Workspace: TaskScheduler allInstances do: [ :each | each stop ].
> > Then I deleted the category and classes (or use Monticello to unload the package). > thanks, amir.. but i did this in the wrong order.. oops! > However, there was still one method remaining. So, search for this method and delete it: > i did this, but my system is still a wreck.. thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by sebastianconcept@gmail.co
Sebastian,
On 03.01.2011, at 20:56, Sebastian Sastre wrote:
I use Sixx for moving my data back and forth between pharo and gemstone. The only problem I discovered regarding resources was the temporary object memory of gemstone. But there is a way to prevent this by commiting chunks of a string to the server. So this scales well. My problems were always encoding and streams. But I changed Sixx to use grease for things like cr and lf. And strings are exported as type String with default encoding of utf-8. At least this is changed in gemstone. I wanted to synchronize the sources for gemstone and pharo but didn't find time so far. Most of the rough edges of Sixx are IMHO smoothed. If it comes to scalability problems than it will be time to integrate some pull parser stuff into the scenario. Ken Treis did it once. And the xml parser is moving forward quite quickly. So if there is a more "standard" pull parser available it will definitely useful to incorporate Ken Treis' changes into Sixx. From then on the scalibility problems shouldn't be that big. I think here ReferenceStream and Sixx work similar by writing an object on first encounter which leads to an entry in a lookup table and every later appearance results in a reference. Fits perfectly fine into a pull parser scenario. So I can't really state anything about scalibility because I would need to check first. But I don't see real problems in the approach only things missing. Norbert
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Lukas Renggli
On 03.01.2011, at 20:55, Lukas Renggli wrote: >>> SIXX doesn't scale. >>> >> Why not? Where do you see the problem? > > The problem is size and subsequently it takes a very long time to read > and write. Even for small sites you end up with megabytes of XML. > You are right. XML is always very chatty. Having an oververbose format in string and a resource intensive representation like DOM does not help when you are looking at scalability. To me scalability includes cross-platform handling as well. So there is less choice than to use the most reliable format/protocol available. And that seems to be XML with an utf-X encoding. > At the time I tried to use SIXX (admittedly this is many years ago) > then XML parser couldn't read properly such large files. The xml parser that we used to have and the one we have now have less in common. The actual one is pretty good. And there is a talented developer that cares a lot about improving things. If there are still problems I promise he is all ears. Norbert _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Lukas Renggli
On 03.01.2011, at 20:58, Lukas Renggli wrote:
Ok, you are right. I'm looking again from the cross-platform view. Sixx is changed to support blocks (in gemstone at least). It may not support all kind of blocks but basic ones it does. The rest is like CompiledMethods. AFAIK there is no cross-platform format for things like CompiledMethod so there is less chance to have something reliable. I try to be pragmatic and from this point of view the support is quite sufficient. Norbert _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Came on, almost nothing deals with persistence of blocks or closures or compiled methods.
It's not only hard but a whole different problem related to distributed computing (or multi VM computing) with objects which is another beast. In that field, chances are that: 1. it's going to be your worst idea ever (see Martin Fowler's First Law of Distributed Object Design) 2. you don't need that 3. if you do it, by the time you have it, everything was reinvented in a simpler way (so its usability will scale better and will make you feel miserable) On Jan 4, 2011, at 8:58 AM, Norbert Hartl wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |