[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
On Mon, Oct 13, 2008 at 13:47, Per Cederberg <[EMAIL PROTECTED]> wrote: > For version 1.5 I think we should consider having a nice little > download web page where you can customize your packed version of > MochiKit. I created a little dummy UI to show what I mean: > > http://www.percederberg.net/mochikit/pack.html Yes, yes, excellent - +1 on that from me. Minor usability pointer: When unselecting a module, instead of unselecting everything that depends on it - highlight the relevant part of "uses XXX" of those in some /error/ color. cheers, Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
I have seen many problems with MochiKit.Selector while testing MochiKit.Query module. As `Per Cederberg` is preparing for 1.4 release, I think MochiKit.Selector should not be included in 1.4, but let we get something really useful with Sizzle which is going to be integrated in MochiKit (hopefully MochiKit 1.5)... - Amit Mendapara --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Mon, Oct 13, 2008 at 14:43, Amit Mendapara <[EMAIL PROTECTED]> wrote: > I have seen many problems with MochiKit.Selector while testing > MochiKit.Query module. You would be helping if you submitted these as bug-reports. Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
I'd appreciate bug reports for the MochiKit.Selector module in Trac or here on the list. I've got 1-2 previously here in this thread that I intend to have a look at soon. Either way, I think we are beyond removing MochiKit.Selector entirely for 1.4. I'll update the docs to point out that it is an *experimental* module that is subject to change. Also, I'll add specific notes for those selectors that won't be compatible with the new Sizzle-powered version. Cheers, /Per On Mon, Oct 13, 2008 at 2:43 PM, Amit Mendapara <[EMAIL PROTECTED]> wrote: > > I have seen many problems with MochiKit.Selector while testing > MochiKit.Query module. As `Per Cederberg` is preparing for 1.4 > release, I think MochiKit.Selector should not be included in 1.4, but > let we get something really useful with Sizzle which is going to be > integrated in MochiKit (hopefully MochiKit 1.5)... > > - Amit Mendapara > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Mon, Oct 13, 2008 at 14:52, Per Cederberg <[EMAIL PROTECTED]> wrote: > Also, I'll add > specific notes for those selectors that won't be compatible with the > new Sizzle-powered version. Assuming the bug in Sizzle that causes [attribute] to fail will be fixed, the only ones that will not work are :root and :*-of-type. I think we are decided to Sizzle and these are both rare and probably take an effort to add to Sizzle. -- so, you could go further than adding a notice and just deprecate them right away. Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Oct 13, 5:52 pm, "Per Cederberg" <[EMAIL PROTECTED]> wrote: > I'd appreciate bug reports for the MochiKit.Selector module in Trac or > here on the list. I've got 1-2 previously here in this thread that I > intend to have a look at soon. Once, I filed a bug report on the trac (related to Sortables), but I was unable to change/comment it later. That's why I never submitted again. Anyway, I will prepare one on MochiKit.Selector this night and will post here in this thread instead... - Amit Mendapara --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara <[EMAIL PROTECTED]> wrote: > Once, I filed a bug report on the trac (related to Sortables), but I > was unable to change/comment it later. That's why I never submitted > again. Yes, this is very unfortunate. I used to have the same problem, so I hear you loud and clear. The problem is the amount of spam that we'd otherwise receive in bug reports. Don't know if there is some newer version of Trac that fixes this that we could install on the server. Or if there is some other solution that would work. Until that happens, emailing to this list or directly to the bug owner should work. Sorry about that. Cheers, /Per --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Mon, Oct 13, 2008 at 15:24, Per Cederberg <[EMAIL PROTECTED]> wrote: > On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara > <[EMAIL PROTECTED]> wrote: >> Once, I filed a bug report on the trac (related to Sortables), but I >> was unable to change/comment it later. That's why I never submitted >> again. > > Yes, this is very unfortunate. I used to have the same problem, so I > hear you loud and clear. > > The problem is the amount of spam that we'd otherwise receive in bug > reports. Don't know if there is some newer version of Trac that fixes > this that we could install on the server. Or if there is some other > solution that would work. Until that happens, emailing to this list or > directly to the bug owner should work. Sorry about that. Do we have a procedure for adding user accounts to Trac, other than simply "Ask Bob"? cheers, Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
The version of trac is okay. See http://trac.edgewall.org/wiki/TracPermissions, you can easily prevent those spams. You can see how TurboGears trac is configured... You can also think about moving MochiKit to Launchpad.net. It's really a good platform to host OpenSource projects with distributed vcs, bug tracking, blueprints and more. Launchpad team has already created a project for MochiKit (so that no one then MochiKit team can claim the ownership, you can contact Launchpad team to get ownership rights). - Amit Mendapara On Oct 13, 6:24 pm, "Per Cederberg" <[EMAIL PROTECTED]> wrote: > On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara > > <[EMAIL PROTECTED]> wrote: > > Once, I filed a bug report on the trac (related to Sortables), but I > > was unable to change/comment it later. That's why I never submitted > > again. > > Yes, this is very unfortunate. I used to have the same problem, so I > hear you loud and clear. > > The problem is the amount of spam that we'd otherwise receive in bug > reports. Don't know if there is some newer version of Trac that fixes > this that we could install on the server. Or if there is some other > solution that would work. Until that happens, emailing to this list or > directly to the bug owner should work. Sorry about that. > > Cheers, > > /Per --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
Well, the login database is outside of trac since we're using basic auth to login and they are the same credentials that give svn commit access. Disabling anonymous commenting is something that I did because I couldn't be bothered to implement a better spam filter or maintain it. I'm not really sold on launchpad, I think bzr would be too much of a barrier to entry for many people. I would certainly consider moving to google code though, because that would be easy enough. All of our other open source projects are there these days. People that want to use distributed vcs to keep a local branch can do so easily enough with a central svn repo. On Mon, Oct 13, 2008 at 6:47 AM, Amit Mendapara <[EMAIL PROTECTED]> wrote: > > The version of trac is okay. See > http://trac.edgewall.org/wiki/TracPermissions, > you can easily prevent those spams. You can see how TurboGears trac is > configured... > > You can also think about moving MochiKit to Launchpad.net. It's really > a good platform to host OpenSource projects with distributed vcs, bug > tracking, blueprints and more. Launchpad team has already created a > project for MochiKit (so that no one then MochiKit team can claim the > ownership, you can contact Launchpad team to get ownership rights). > > - Amit Mendapara > > On Oct 13, 6:24 pm, "Per Cederberg" <[EMAIL PROTECTED]> wrote: >> On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara >> >> <[EMAIL PROTECTED]> wrote: >> > Once, I filed a bug report on the trac (related to Sortables), but I >> > was unable to change/comment it later. That's why I never submitted >> > again. >> >> Yes, this is very unfortunate. I used to have the same problem, so I >> hear you loud and clear. >> >> The problem is the amount of spam that we'd otherwise receive in bug >> reports. Don't know if there is some newer version of Trac that fixes >> this that we could install on the server. Or if there is some other >> solution that would work. Until that happens, emailing to this list or >> directly to the bug owner should work. Sorry about that. >> >> Cheers, >> >> /Per > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Mon, Oct 13, 2008 at 17:19, Bob Ippolito <[EMAIL PROTECTED]> wrote: > I'm not really sold on launchpad, I think bzr would be too much of a > barrier to entry for many people. I would certainly consider moving to > google code though, because that would be easy enough. All of our > other open source projects are there these days. People that want to > use distributed vcs to keep a local branch can do so easily enough > with a central svn repo. I want to support this, i.e. if the plan is to abandon Trac - Google Code is much more fitting than Launchpad. cheers, Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Migrate to Google Code?
I've been considering this for a while but didn't want to put forth the effort at the time, but I think that with the release of 1.4 it would be a good time to migrate from the Mochi Media hosted Trac and SVN over to something else. My personal preference is Google Code because we already use that for our other open source projects and it wouldn't require transitioning from a mainstream VC solution to something more obscure (e.g. launchpad, github). Per, do you have any thoughts on this? -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
Exactly what I was thinking - nice work! > -Original Message- > From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Arnar Birgisson > Sent: Monday, October 13, 2008 6:24 AM > To: Per Cederberg > Cc: MochiKit > Subject: [mochikit] Re: Including MochiKit.DragAndDrop and > MochiKit.Sortable in the packed version? > > > On Mon, Oct 13, 2008 at 13:47, Per Cederberg <[EMAIL PROTECTED]> wrote: > > For version 1.5 I think we should consider having a nice little > > download web page where you can customize your packed version of > > MochiKit. I created a little dummy UI to show what I mean: > > > > http://www.percederberg.net/mochikit/pack.html > > Yes, yes, excellent - +1 on that from me. > > Minor usability pointer: When unselecting a module, instead of > unselecting everything that depends on it - highlight the relevant > part of "uses XXX" of those in some /error/ color. > > cheers, > Arnar > > > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.173 / Virus Database: 270.8.0/1722 - Release Date: 10/13/2008 > 7:50 AM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
I had intended to build exactly that years ago, but never got around to it... mostly because it's hard to do client side and I didn't want that feature to be dependent on some server-side script. My thinking was that we'd keep packed versions of every module (so that we could continue to use the Java based packer, instead of implementing a JavaScript version)[1] and some client-side could could XHR them all down and concatenate them in the correct order, but the problem is allowing the user to actually download that text. Using the pasteboard would work I guess, but that's not a nice solution. I suppose we could set something up where the client just does a POST to some URL (maybe an app engine service or something) and the server simply echos it back with a Content-Disposition header that forces download. [1] But maybe it would be reasonable to write an entirely JS based packer with Narcissus http://mxr.mozilla.org/mozilla/source/js/narcissus/ -- are there any other projects like this that I'm not aware of? -bob On Mon, Oct 13, 2008 at 4:47 AM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Seeing that this wasn't just an omission, I won't change it for the 1.4 > version. > > For version 1.5 I think we should consider having a nice little > download web page where you can customize your packed version of > MochiKit. I created a little dummy UI to show what I mean: > > http://www.percederberg.net/mochikit/pack.html > > If we plunge forward and start adding more extension modules (as > suggested here before), I think such a UI would be important to keep > all users happy. > > Cheers, > > /Per > > On Wed, Oct 8, 2008 at 3:44 PM, Arnar Birgisson <[EMAIL PROTECTED]> wrote: >> Hi Per, >> >> On Wed, Oct 8, 2008 at 15:38, Per Cederberg <[EMAIL PROTECTED]> wrote: >>> The packed version of MochiKit still doesn't include the modules >>> DragAndDrop and Sortable. I found a previous discussion of that in >>> this thread: >>> >>> http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99 >>> >>> None of the two modules have been much modified lately, so perhaps >>> they are now stable? Otherwise, I think we should make the docs >>> clearer regarding their status and how to use them. >> >> Including them is fine with me, but for my own purposes I don't use >> that.. since for me MochiKit serves purely as a utility library rather >> than one of UI elements. I suspect there are others in a similar >> situation. >> >> What we really should do, and it should not be too hard, is make >> several packed versions. Basically for every module we'd provide a >> "dependency-closed" packed version - i.e. one that includes that >> module and all of its dependencies. Modifying the "packed" script to >> perform this should be doable. >> >> If people don't like the idea of so many packed versions, perhaps we >> could decide on two or three "feature-sets" and provide packed >> versions of these. I know MochiKit is not that big, and download time >> is not really the issue - but bandwidth can be an issue for the host. >> >> cheers, >> Arnar >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
Seeing that this wasn't just an omission, I won't change it for the 1.4 version. For version 1.5 I think we should consider having a nice little download web page where you can customize your packed version of MochiKit. I created a little dummy UI to show what I mean: http://www.percederberg.net/mochikit/pack.html If we plunge forward and start adding more extension modules (as suggested here before), I think such a UI would be important to keep all users happy. Cheers, /Per On Wed, Oct 8, 2008 at 3:44 PM, Arnar Birgisson <[EMAIL PROTECTED]> wrote: > Hi Per, > > On Wed, Oct 8, 2008 at 15:38, Per Cederberg <[EMAIL PROTECTED]> wrote: >> The packed version of MochiKit still doesn't include the modules >> DragAndDrop and Sortable. I found a previous discussion of that in >> this thread: >> >> http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99 >> >> None of the two modules have been much modified lately, so perhaps >> they are now stable? Otherwise, I think we should make the docs >> clearer regarding their status and how to use them. > > Including them is fine with me, but for my own purposes I don't use > that.. since for me MochiKit serves purely as a utility library rather > than one of UI elements. I suspect there are others in a similar > situation. > > What we really should do, and it should not be too hard, is make > several packed versions. Basically for every module we'd provide a > "dependency-closed" packed version - i.e. one that includes that > module and all of its dependencies. Modifying the "packed" script to > perform this should be doable. > > If people don't like the idea of so many packed versions, perhaps we > could decide on two or three "feature-sets" and provide packed > versions of these. I know MochiKit is not that big, and download time > is not really the issue - but bandwidth can be an issue for the host. > > cheers, > Arnar > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
Scary stuff. JS in JS... :-) I also gave the download issue some thought. Seems it would be possible to spoof a download in IE and Firefox (with privilege escalation warning). But not on Safari. And anyway, it would be an ugly and messy hack. So my next thought would be to create something in Flash that could save a file locally. We can even supply it with the actual text file content from JS just like Bob explained. Is that doable? I don't have a license for that stuff and have never worked in Flash myself, so perhaps I'm just dead wrong here. Third option would be to just open a window with the packed text and ask the user to do Ctrl-S. Perhaps by setting the window title or something. Cheers, /Per On Mon, Oct 13, 2008 at 6:29 PM, Bob Ippolito <[EMAIL PROTECTED]> wrote: > I had intended to build exactly that years ago, but never got around > to it... mostly because it's hard to do client side and I didn't want > that feature to be dependent on some server-side script. > > My thinking was that we'd keep packed versions of every module (so > that we could continue to use the Java based packer, instead of > implementing a JavaScript version)[1] and some client-side could could > XHR them all down and concatenate them in the correct order, but the > problem is allowing the user to actually download that text. Using the > pasteboard would work I guess, but that's not a nice solution. > > I suppose we could set something up where the client just does a POST > to some URL (maybe an app engine service or something) and the server > simply echos it back with a Content-Disposition header that forces > download. > > [1] But maybe it would be reasonable to write an entirely JS based > packer with Narcissus > http://mxr.mozilla.org/mozilla/source/js/narcissus/ -- are there any > other projects like this that I'm not aware of? > > -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Migrate to Google Code?
Google code seems fine by me. Especially if we get better access for normal users. The only issue I come to think of is that the mochikit.com web site automatically updates from svn trunk. Don't know if it would be easy to keep that link. Something which is pretty good to have from time to time. Especially when we are linking to examples and demos that are actually inside the project repo (not just on the web site). On the other hand, we often forget to make_docs.py or pack.py before committing to svn. So perhaps it would be good to have these steps performed automatically by some automated web publisher. So that we wouldn't need the packed version in svn... Just my random thoughts. Cheers, /Per On Mon, Oct 13, 2008 at 6:17 PM, Bob Ippolito <[EMAIL PROTECTED]> wrote: > > I've been considering this for a while but didn't want to put forth > the effort at the time, but I think that with the release of 1.4 it > would be a good time to migrate from the Mochi Media hosted Trac and > SVN over to something else. My personal preference is Google Code > because we already use that for our other open source projects and it > wouldn't require transitioning from a mainstream VC solution to > something more obscure (e.g. launchpad, github). > > Per, do you have any thoughts on this? > > -bob > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
AFAIK Flash can't save to disk in that manner either. You can build Flash content with free tools though (Adobe Flex 2 SDK, MTASC, haXe, etc.). -bob On Mon, Oct 13, 2008 at 11:51 AM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Scary stuff. JS in JS... :-) > > I also gave the download issue some thought. Seems it would be > possible to spoof a download in IE and Firefox (with privilege > escalation warning). But not on Safari. And anyway, it would be an > ugly and messy hack. > > So my next thought would be to create something in Flash that could > save a file locally. We can even supply it with the actual text file > content from JS just like Bob explained. Is that doable? I don't have > a license for that stuff and have never worked in Flash myself, so > perhaps I'm just dead wrong here. > > Third option would be to just open a window with the packed text and > ask the user to do Ctrl-S. Perhaps by setting the window title or > something. > > Cheers, > > /Per > > On Mon, Oct 13, 2008 at 6:29 PM, Bob Ippolito <[EMAIL PROTECTED]> wrote: >> I had intended to build exactly that years ago, but never got around >> to it... mostly because it's hard to do client side and I didn't want >> that feature to be dependent on some server-side script. >> >> My thinking was that we'd keep packed versions of every module (so >> that we could continue to use the Java based packer, instead of >> implementing a JavaScript version)[1] and some client-side could could >> XHR them all down and concatenate them in the correct order, but the >> problem is allowing the user to actually download that text. Using the >> pasteboard would work I guess, but that's not a nice solution. >> >> I suppose we could set something up where the client just does a POST >> to some URL (maybe an app engine service or something) and the server >> simply echos it back with a Content-Disposition header that forces >> download. >> >> [1] But maybe it would be reasonable to write an entirely JS based >> packer with Narcissus >> http://mxr.mozilla.org/mozilla/source/js/narcissus/ -- are there any >> other projects like this that I'm not aware of? >> >> -bob > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Migrate to Google Code?
Keeping the commit hooks for updating the site is possible, I'll probably set up a svn mirror at or near the current svn repository and our internal tools will be able to update that. Might have to hook up some kind of mail hook thing to have it happen "instantly" though, I don't think google code has a HTTP post-commit "web hook". Anyway, I can take care of it. These are the sorts of reasons that I didn't bother before, but I'm willing to do it now :) I do like keeping the packed version and docs in svn, but we could have a process that automatically does it and performs a second commit when necessary (but setting that up might be a little too much work to bother). -bob On Mon, Oct 13, 2008 at 12:02 PM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Google code seems fine by me. Especially if we get better access for > normal users. > > The only issue I come to think of is that the mochikit.com web site > automatically updates from svn trunk. Don't know if it would be easy > to keep that link. Something which is pretty good to have from time to > time. Especially when we are linking to examples and demos that are > actually inside the project repo (not just on the web site). > > On the other hand, we often forget to make_docs.py or pack.py before > committing to svn. So perhaps it would be good to have these steps > performed automatically by some automated web publisher. So that we > wouldn't need the packed version in svn... > > Just my random thoughts. > > Cheers, > > /Per > > On Mon, Oct 13, 2008 at 6:17 PM, Bob Ippolito <[EMAIL PROTECTED]> wrote: >> >> I've been considering this for a while but didn't want to put forth >> the effort at the time, but I think that with the release of 1.4 it >> would be a good time to migrate from the Mochi Media hosted Trac and >> SVN over to something else. My personal preference is Google Code >> because we already use that for our other open source projects and it >> wouldn't require transitioning from a mainstream VC solution to >> something more obscure (e.g. launchpad, github). >> >> Per, do you have any thoughts on this? >> >> -bob >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
On Mon, Oct 13, 2008 at 2:24 PM, Arnar Birgisson <[EMAIL PROTECTED]> wrote: > Minor usability pointer: When unselecting a module, instead of > unselecting everything that depends on it - highlight the relevant > part of "uses XXX" of those in some /error/ color. I fooled around a bit with the visual effects instead... http://www.percederberg.net/mochikit/pack.html Cheers, /Per --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
On Mon, Oct 13, 2008 at 22:09, Per Cederberg <[EMAIL PROTECTED]> wrote:
> I fooled around a bit with the visual effects instead...
> http://www.percederberg.net/mochikit/pack.html
Ah, nice, very nice.
As for the other thing (generating the pack) - I don't think there is
a good, clean way to do it on the client side and probably something
server side (it can be dead-simple) is the way to go.
Although, there is one outrageous possibility: We could pregenerate
all possible combinations of modules. Now, before you call me crazy,
note that even if 14 modules could potentially mean 2^14~=16k
different combinations, the dependency graph puts severe restrictions
on that. So for fun, I decided to see how many there really are. Given
the dependency specs Per used in the above html file, there are
exactly 1952 possible combinations such that all dependencies are
included :D
Now, generating these 1952 files every time there is a commit might
seem stupid, but it is actually doable :)
Ok, now feel free to call me crazy.
Below this message is a Haskell program to find all legal combinations.
cheers,
Arnar
module Main where
import Control.Concurrent (forkIO)
import Control.Concurrent.MVar
import Data.Maybe (fromJust)
import Data.List (nub)
-- Modules in topological order, i.e.
-- a module must appear after all of its
-- dependencies
dependencies = [
("Base",[]),
("DateTime",["Base"]),
("Format",["Base"]),
("Iter",["Base"]),
("Async",["Base"]),
("DOM",["Base"]),
("Style",["Base"]),
("Color",["DOM", "Style"]),
("Logging",["Base"]),
("LoggingPane",["Logging"]),
("Selector",["DOM", "Style"]),
("Signal",["DOM", "Style"]),
("Visual",["Color"]),
("DragAndDrop",["Iter","Signal","Visual"]),
("Sortable",["DragAndDrop"])
]
modules = map fst dependencies
antichains :: MVar (Maybe [String]) -> IO ()
antichains channel = antichains' [] modules >> putMVar channel Nothing
where
antichains' :: [String] -> [String] -> IO ()
antichains' ac [] = putMVar channel (Just ac) >> return ()
antichains' ac (candidate:rest) =
do if ac `accepts` candidate
then antichains' (candidate:ac) rest
else return ()
antichains' ac rest
chain `accepts` candidate =
all (\c -> not . elem c
$ fromJust
$ lookup candidate dependencies) chain
closure :: [String] -> [String]
closure ms =
let missing = nub $ filter (not . flip elem ms)
$ concatMap (fromJust . flip lookup dependencies) ms
in
if null missing
then ms
else closure (ms ++ missing)
printer :: MVar () -> MVar (Maybe [String]) -> IO ()
printer stop in_ =
do v <- takeMVar in_
case v of
Just xs -> putStrLn $ show $ closure xs
Nothing -> putMVar stop ()
printer stop in_
main :: IO ()
main = do chan <- newEmptyMVar
stop <- newEmptyMVar
forkIO $ printer stop chan
forkIO $ antichains chan
takeMVar stop
return ()
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
Hi again, On Mon, Oct 13, 2008 at 22:23, Arnar Birgisson <[EMAIL PROTECTED]> wrote: > Although, there is one outrageous possibility: We could pregenerate > all possible combinations of modules. Now, before you call me crazy, > note that even if 14 modules could potentially mean 2^14~=16k > different combinations, the dependency graph puts severe restrictions > on that. So for fun, I decided to see how many there really are. Given > the dependency specs Per used in the above html file, there are > exactly 1952 possible combinations such that all dependencies are > included :D While I should probably point out that my last message was tongue-in-cheek, there was also a glaring bug in my algorithm. After fixing that and rerunning, the possible combinations are *merely* 817 :) The correct code will appear on my blog in a few minutes. http://www.hvergi.net/ cheers, Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
