[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?
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: 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 -~--~~~~--~~--~--~---
