| 00:30.18 | *** join/#storm sidnei (~sidnei@201.34.90.137) |
| 03:19.12 | *** join/#storm bigdog (~scmikes@8.8.197.72) |
| 04:09.19 | *** join/#storm lakin (~lakin@S010600265af23ae6.cg.shawcable.net) |
| 05:27.52 | *** join/#storm pingveno (~pingveno@c-98-246-133-8.hsd1.or.comcast.net) |
| 05:41.42 | *** join/#storm lakin (~lakin@S010600265af23ae6.cg.shawcable.net) |
| 06:24.53 | *** join/#storm zmijunkie_ (~sascha@i59F5EDEA.versanet.de) |
| 06:46.07 | *** join/#storm stub (~stub@125.24.139.124.adsl.dynamic.totbb.net) |
| 06:46.07 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 08:02.35 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 08:18.44 | *** join/#storm esteve (~quassel@cli-5b7ee9bd.bcn.adamo.es) |
| 08:25.10 | *** join/#storm stub (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 08:25.10 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 09:10.51 | *** join/#storm yosafbridge (~yosafbrid@li125-242.members.linode.com) |
| 09:24.53 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 09:25.21 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 10:12.39 | *** join/#storm yosafbridge (~yosafbrid@li125-242.members.linode.com) |
| 10:29.48 | *** join/#storm stub (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 10:29.48 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 10:57.43 | *** join/#storm stub (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 10:57.43 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 11:58.03 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 11:58.04 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 11:58.43 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 11:58.46 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 11:59.21 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 11:59.23 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:00.18 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:00.20 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:00.58 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:01.14 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:01.38 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:01.40 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:02.49 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:02.52 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:03.56 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:03.58 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:05.07 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:05.10 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:05.47 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:05.50 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:06.42 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:06.44 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:07.13 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:07.17 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:08.14 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:08.14 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:09.17 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:09.21 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:10.34 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:10.37 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:11.18 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:11.21 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:12.01 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:12.04 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:12.51 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:12.55 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:14.08 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:14.10 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:17.45 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:17.49 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:19.25 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:19.38 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:20.34 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:20.38 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:36.14 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:36.16 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:38.41 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:38.47 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:39.38 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:39.40 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:41.00 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:41.04 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:42.16 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:42.21 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:50.05 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:50.09 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:50.50 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:50.50 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 12:53.02 | *** join/#storm stub1 (~stub@125.24.127.77.adsl.dynamic.totbb.net) |
| 12:53.05 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 13:10.00 | *** join/#storm niemeyer (~niemeyer@12.236.237.2) |
| 13:14.55 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 13:52.08 | *** join/#storm sidnei (~sidnei@200-203-3-152.cslce701.dsl.brasiltelecom.net.br) |
| 14:23.34 | *** join/#storm jtv_ (u2720@gateway/web/irccloud.com/x-rowjsynwqdbptidn) |
| 15:00.01 | *** join/#storm lakin (~lakin@S010600265af23ae6.cg.shawcable.net) |
| 15:36.55 | *** join/#storm RaceCondition (~erik@gprs-inet-65-43.elisa.ee) |
| 15:37.42 | RaceCondition | where could I find a guide/manual on how to set up Storm with Twisted? |
| 15:38.01 | RaceCondition | either with PostgreSQL or SQLite, or both |
| 15:39.43 | jkakar | RaceCondition: Hi. |
| 15:39.49 | RaceCondition | jkakar: hi :) |
| 15:39.58 | jkakar | RaceCondition: I don't think we have any documentation about Storm+Twisted specifically. |
| 15:40.13 | jkakar | RaceCondition: What you should probably do is look at the code (in trunk) in storm.twisted.transact. |
| 15:40.33 | jkakar | RaceCondition: Basically, you give it a thread pool and then call Transactor.transact with the function you want to run in a transaction. |
| 15:41.04 | jkakar | RaceCondition: It returns a Deferred while it takes care of running the function in a thread. It'll also retry up to 3 times if something bad happens (ie, DisconnectionError or similar). |
| 15:41.06 | RaceCondition | oh, in the trunk... good |
| 15:41.16 | jkakar | Yep. It landed a few weeks back. |
| 15:41.25 | RaceCondition | so there's also an example in the trunk that I can use? |
| 15:42.16 | jkakar | RaceCondition: Probably just the unit tests. |
| 15:42.17 | RaceCondition | looks like exactly what we need |
| 15:42.37 | jkakar | RaceCondition: The relevant ones are in $trunk/tests/twisted/transact.py. |
| 15:42.40 | *** join/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 15:42.46 | jkakar | Hiya magmatt. :) |
| 15:42.59 | RaceCondition | good, I'll read those |
| 15:43.04 | magmatt | jkakar: hi |
| 15:48.49 | RaceCondition | jkakar: the code in this e-mail is not related to the stuff in the current trunk? https://lists.ubuntu.com/archives/storm/2009-April/000963.html |
| 15:53.02 | RaceCondition | and I can't find $trunk/tests/twisted/transact.py :) |
| 15:54.17 | jkakar | looks |
| 15:55.15 | jkakar | RaceCondition: No, there's a branch that therve pushed a couple of years that provides deeper (than using a thread pool) integration with Twisted. |
| 15:55.30 | jkakar | RaceCondition: It is not merged to trunk and has been stalled for a couple of years, so I doubt it'll get in anytime soon. |
| 15:55.47 | magmatt | What do you typically use validators for? I know what they do, I'm curious how people are actually using them. |
| 15:55.52 | jkakar | RaceCondition: If you can't find that file then your branch must be out-of-date. Do 'bzr branch lp:storm' and you should find it. |
| 15:56.23 | jkakar | magmatt: I've used them to run regular expressions to validate email addresses. |
| 15:56.48 | magmatt | What about changing 'N' into False for a boolean? Too much? |
| 15:57.10 | jkakar | magmatt: I'd use it for that, too. |
| 15:57.24 | jkakar | magmatt: I find it hard to know how much of that kind of thing is too much sometimes. |
| 15:58.05 | magmatt | jkakar: yeah, I feel like I'm introducing too much magic sometimes -- magic that will behave unlike expectations down the road |
| 15:58.06 | jkakar | magmatt: Most of my Storm code has a clear model/presentation separation, so I would typically put the logic to convert 'N' to False in the presentation layer and have the model only accept bool's... but doing what you suggest sounds fine too. |
| 15:58.24 | jkakar | magmatt: Magic is evil, I try to avoid it as much as possible. |
| 15:59.12 | magmatt | jkakar: let me describe my real problem and get your input |
| 15:59.21 | magmatt | I have a model that is mostly used for webapps |
| 15:59.32 | magmatt | both receiving data from webapps and giving it back data |
| 15:59.42 | jkakar | Okay. |
| 15:59.50 | magmatt | but I also get data import files from third parties that I need to import/merge with records |
| 16:00.17 | magmatt | they give very dirty data (lots of extra whitespace, "N" for False, etc...) |
| 16:00.28 | magmatt | They're excel files, so everything's pretty much a string to begin with. |
| 16:00.37 | jkakar | I see. |
| 16:00.44 | magmatt | In order to merge records, I have to deal with cleaned data (strip the whitespace) |
| 16:00.51 | magmatt | to determine how the merge should go |
| 16:01.08 | jkakar | My initial reaction is that you need a pipeline. |
| 16:01.23 | jkakar | upload dirty data -> sanitize into clean form -> import/merge in model |
| 16:01.34 | magmatt | jkakar: I agree. |
| 16:01.55 | magmatt | But if my santization logic is in validators... |
| 16:01.56 | RaceCondition | jkakar: I see, I thought that code can't be using a thread pool because it looks fully async using coroutines |
| 16:01.59 | jkakar | You model will always expect clean data, whatever that means... the mess to deal with dirty data will just be a processing stage. |
| 16:02.13 | RaceCondition | jkakar: and I was looking at http://twistedmatrix.com/trac/browser/trunk |
| 16:02.16 | jkakar | RaceCondition: I don't think I know whatmeans. :) |
| 16:02.25 | jkakar | what that means, even. |
| 16:03.06 | jkakar | magmatt: If your sanitization logic is in validators I suspect your life will get hard at some point. That kind of "design" is too generic... you can't change it if you want to and every bit will go through the same validation path. |
| 16:03.24 | jkakar | Maybe it'll work well, but I'd personally avoid it. |
| 16:03.36 | RaceCondition | jkakar: I mean, therve's code uses Python generators aka coroutines, i.e. it doesn't use a separate thread but probably DB level callbacks/polling |
| 16:03.49 | magmatt | jkakar: yes, I see what you mean. |
| 16:04.16 | RaceCondition | therve: are you here? :P |
| 16:04.27 | jkakar | RaceCondition: I'm not sure how it works anymore, I haven't looked at it in years. |
| 16:04.39 | jkakar | He's probably hiding. :) |
| 16:04.41 | magmatt | I originally wrote it pipelined, but felt like I was duplicating the role of the validators. So I've now written it with validators and am thinking I've gone too far |
| 16:04.48 | magmatt | jkakar: Thanks for your thoughts |
| 16:04.52 | jkakar | magmatt: Anytime. :) |
| 16:05.07 | jkakar | magmatt: It helps me to talk about these things... I ask myself the same kinds of questions, quite often. |
| 16:05.24 | jkakar | magmatt: In general, I like designs where you have layers or components that have a simple input/output contract. |
| 16:05.33 | jkakar | magmatt: They're easy to compose and easy to reason about. |
| 16:05.41 | magmatt | jkakar: and easy to test :) |
| 16:05.45 | RaceCondition | jkakar: I see; well, I'll try to catch him.. but, I still can't find $trunk/tests/twisted/transact.py... was I looking at the right URL? |
| 16:05.55 | jkakar | magmatt: When too many behaviours are implicit in some (apparently simple path) things get hard. |
| 16:06.25 | jkakar | RaceCondition: http://bazaar.launchpad.net/~storm/storm/trunk/view/head:/tests/twisted/transact.py |
| 16:06.37 | jkakar | magmatt: Exactly. :) |
| 16:06.38 | RaceCondition | ah, I see |
| 16:07.29 | magmatt | I think I'm going to avoid changing types in my validators as a first rule -- that will eliminate a lot of magic (except str to unicode) |
| 16:24.38 | RaceCondition | does anybody have a working snippet of code that uses storm.twisted? |
| 16:35.24 | RaceCondition | jkakar: I just realised that I was looking at Twisted's repository instead of Storm'sâmust have looked really stupid |
| 16:35.58 | jkakar | RaceCondition: Hehe, I guessed you'd figure it out soon enough. :) |
| 16:36.20 | RaceCondition | that's what happens when you're learning two new non trivial things at once |
| 16:36.27 | jkakar | RaceCondition: I haven't tested it, but this might help: http://paste.ubuntu.com/644876/ |
| 16:37.04 | jkakar | Don't be too scared by the 'zope' stuff. It's just a way to globally registered named stores and easily get access to them in threads. |
| 16:37.15 | RaceCondition | jkakar: I like ZCA :) |
| 16:37.19 | jkakar | It doesn't draw in anymore dependencies than Twisted already needs (it uses zope.component and zope.interface). |
| 16:37.41 | jkakar | RaceCondition: Yeah, me too. At least, when the uses are straightforward. I think people go a bit crazy with adapters and things sometimes. |
| 16:37.54 | RaceCondition | yeah, overengineering sucks |
| 16:38.07 | RaceCondition | that pasteâit could use the @transact decorator, but it chooses not to, right? |
| 16:38.32 | jkakar | RaceCondition: Right. |
| 16:38.46 | jkakar | RaceCondition: Well, actually, no. |
| 16:38.56 | jkakar | RaceCondition: The @transact decorator is for *methods*, not bare functions. |
| 16:39.10 | jkakar | RaceCondition: It should probably be called @transact_method or something to be more clear. |
| 16:39.11 | RaceCondition | yeah, I understand that, but IF it were a method |
| 16:39.26 | jkakar | RaceCondition: Yep, then it would probably be a good choice. |
| 16:39.42 | RaceCondition | I could just write a decorator for functions, or a decorator factory that is already bound to a transactor |
| 16:40.32 | RaceCondition | and, instead of doing `zstorm = getUtility(...); store = ...;` in each individual transacted callable, I could write my own wrapper to pass a store as the first argument, correct? |
| 16:40.43 | jkakar | RaceCondition: No. |
| 16:40.49 | jkakar | RaceCondition: Well, maybe. |
| 16:40.54 | RaceCondition | ah, threadlocals? |
| 16:41.06 | jkakar | RaceCondition: Yeah, because of the DB-API drivers in Python. |
| 16:41.17 | jkakar | RaceCondition: You need to always use a Store and the objects you fetch from it in the same thread. |
| 16:41.19 | RaceCondition | but, still, the decorator code is run inside the same thread.. no? |
| 16:41.35 | jkakar | RaceCondition: So you shouldn't return Storm objects from your transaction thread, for example. |
| 16:41.42 | RaceCondition | yes, aware of that |
| 16:41.46 | jkakar | RaceCondition: It is, yes. |
| 16:42.08 | jkakar | RaceCondition: But the connection used by the Store might have been created in the main thread before you pass it to the function, in which case weird things might happen. |
| 16:43.27 | RaceCondition | `store = zstorm.get('main')` would still be rune in that same transact_function, it's just that there's an inner function that gets that store passed to it |
| 16:43.33 | RaceCondition | or am I missing something? |
| 16:46.25 | RaceCondition | like that: http://dpaste.com/569342/ |
| 16:53.02 | jkakar | looks |
| 16:53.40 | jkakar | RaceCondition: That will work correctly. The wrapped function in the storm_transaction decorator will run in the transaction thread. |
| 16:56.49 | RaceCondition | yep |
| 16:58.35 | RaceCondition | 1 more thing: is the code in $trunk/storm/twisted/transact.py in any way dependent on trunk? or I can use it with the latest release? |
| 17:00.13 | RaceCondition | ...easier to deploy using pip/easy_install that way |
| 17:05.00 | jkakar | RaceCondition: You can use it with the latest release. |
| 17:05.35 | RaceCondition | perfect |
| 17:33.50 | RaceCondition | weird, I'm using the example you gave with the Transactor from storm.twisted.transact, and it gets to deferToThreadPool, and then nothing; i.e. the function that is deferred is never executed |
| 17:35.12 | jkakar | RaceCondition: Uhm. |
| 17:35.56 | jkakar | <PROTECTED> |
| 17:35.56 | jkakar | <PROTECTED> |
| 17:36.02 | jkakar | RaceCondition: ^^ You probably need to put that somewhere. |
| 17:36.05 | RaceCondition | oh |
| 17:36.06 | jkakar | Or something similar. |
| 17:36.22 | RaceCondition | ah, i see |
| 17:36.33 | jkakar | RaceCondition: I always create and configure the threadpool before the reactor starts. But there's other ways to do it. |
| 17:37.12 | RaceCondition | yeah, of course.. the example in storm/tw/transact.py even has that |
| 17:37.23 | RaceCondition | but I used your paste without comparing it |
| 17:38.50 | RaceCondition | now the immediate function passed to deferTo.. is executed, but not the wrapped one |
| 17:39.07 | RaceCondition | pdb to the rescue |
| 17:40.53 | jkakar | Heh |
| 17:40.57 | jkakar | Don't you just love computers? :) |
| 17:41.03 | jkakar | It's such a PITA to even do simple things. |
| 17:41.10 | RaceCondition | yeah |
| 17:41.22 | RaceCondition | turns out I just passed a bad function, but.. why aren't any exceptions printed? |
| 17:41.35 | RaceCondition | I assume Twisted's threading system just swallows it |
| 17:43.50 | RaceCondition | working now (Y) |
| 17:43.50 | mgedmin | deferreds capture exceptions, convert them to Failures, and call any "errbacks" you've registered with your deferred, IIRC |
| 17:44.05 | mgedmin | it's been a while since I used twisted |
| 17:44.08 | RaceCondition | shouldn't Transactor do that for me? |
| 17:45.00 | RaceCondition | oh, nvm, I misread your sentence |
| 17:46.10 | jkakar | RaceCondition: What mgedmin said is right. You need to do something like: deferred.addErrback(error_handler) |
| 17:46.24 | jkakar | error_handler should be a function that takes a single 'failure' argument. |
| 17:46.28 | RaceCondition | jkakar: yes, I have that already :) as I said, I misread what you said |
| 17:46.33 | jkakar | If something bad happens you'll get a Failure instance. |
| 17:46.49 | jkakar | RaceCondition: Ah, okay, cool. Not sure how much you know about Twisted... those issues usually trip people up for awhile. |
| 17:46.53 | RaceCondition | it's just that I was running everything via ipython, and for some reason, things don't work the same then as when running via twistd |
| 17:46.59 | jkakar | Ah, okay. |
| 17:47.05 | RaceCondition | no, I love async stuff and deferreds |
| 17:47.39 | RaceCondition | feel much more at home than with blocking code |
| 17:48.07 | RaceCondition | it's just the reactor thing that I don't understand yet |
| 17:48.49 | jkakar | RaceCondition: Ah, cool. I love async and Deferreds, too. So powerful and you can write such simple, elegant and performant code with those tools. |
| 17:49.23 | RaceCondition | yeah, like in typical JS :P |
| 18:14.51 | RaceCondition | just wondering: what is the purpose for @transact to take `transactor` from self? would different objects that contain business logic be using different transactor instances? |
| 18:15.09 | *** join/#storm keppla (~keppla@p4FD47861.dip.t-dialin.net) |
| 18:18.12 | jkakar | RaceCondition: It's unlikely. More like you'd pass the same Transactor instance to each instance. |
| 18:19.02 | RaceCondition | but why then does the storm.tw.transact.transact decorator use self.transactor? it is expected that the objects __init__ takes it from a shared location? |
| 18:19.20 | RaceCondition | object's |
| 18:20.14 | jkakar | RaceCondition: It's expected that you pass the Transactor instance to each of the objects that uses the decorator. How you pass it is up to you. |
| 18:21.00 | RaceCondition | yeah, I just thought it had some specific purpose |
| 18:25.35 | jkakar | Cool. |
| 18:38.40 | RaceCondition | hmm, actually, if I initialise both the Transactor and the ZStorm object in the same place, I shouldn't have to use zope.component |
| 18:40.51 | jkakar | RaceCondition: That's not actually true. |
| 18:41.04 | RaceCondition | why not? |
| 18:41.22 | jkakar | RaceCondition: Transactor._wrap uses getUtility(IZStorm) when attempting to perform retries. |
| 18:42.13 | RaceCondition | unless I modify Transactor and pass it my global ZStorm instance so it can just access it through self.zstorm |
| 18:43.05 | RaceCondition | no? |
| 18:46.33 | jkakar | RaceCondition: Sure, if you modify it you can do anything you want. :) |
| 18:46.51 | jkakar | I'm off for the day. Be well folks! |
| 18:47.07 | RaceCondition | I mean, using zope.component just to pass around a singleton instance of something seems like an overkill, unless I want it to be overriden |
| 18:47.14 | RaceCondition | jkakar: okay, thanks for all the help! |
| 19:19.43 | *** join/#storm sidnei (~sidnei@200-203-3-152.cslce701.dsl.brasiltelecom.net.br) |
| 20:13.06 | *** join/#storm cime (~cime@93-103-77-51.dynamic.t-2.net) |
| 20:13.22 | cime | hi! is there any Storm build for windows? |
| 20:17.37 | cime | I need Storm on Python 2.7, windows |
| 20:17.42 | cime | do I need to build it from source? |
| 20:42.49 | *** join/#storm yosafbridge (~yosafbrid@li125-242.members.linode.com) |
| 20:53.13 | magmatt | cime: it might not be difficult |
| 20:53.29 | magmatt | I'm not on windows and don't know what bumps you might encounter |
| 23:04.10 | *** part/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 23:19.14 | *** join/#storm m4v (~znc@unaffiliated/m4v) |