DjangoBot: #django-dev

lsoto: hey

fijal: ho

Morning, all.

happy firefox day

it gets released in 45 mins right?

18 mins ago

but you can't load any of the sites

I finally got the page to load a few minutes ago but it still linked to 2.0.0.14

yeah same for me. they probably can't upload the new stuff ;)

aren't they trying to break a record or something...figure they'd have planned (or outsourced) the bandwidth

heh, i was thinking the same thing forsaken

from #firefox: <h1pp1e> download firefox now Windows: http://snurl.com/2jxqw | OS X: http://snurl.com/2jxv2 | Linux: http://snurl.com/2jxqv

mirrors seem pretty responsive, just not the http

does it count on mirrors?

*shrug* i would assume so

the chan says not to link directly to them, so it might get counted through the main site or something

the link changes so fast I couldn't tell if it's a mozilla mirror or some other one some dude set up :)

if I fix #7027 is someone willing to review/commit it? I'm bitten by this right now and probably the fix is not that hard, but if there's no general interest, I just work around it

lsoto: are you familiar how much modified django do you need to run it on top of jython?

jacobkm: hey, you can put me as one who would care about django being able to run on top of pypy

I hereby volunteer to make sure tests pass etc.

fijal: feel free to add yourself to the version one features page -- thanks!

jacobkm: ok

as who?

fijal: with the "old" postgresql_zxjdbc backend it could be ran just applying the robustapply patch

fijal: as I've recently improved the backend, it depends on some extra changes to django I'm about to post as a ticket

basically, it's about extending DatabaseOperations with methods to do python -> db conversion methods (eg: value_to_db_date, value_to_db_decimal)

you can take a look at https://hg.leosoto.com/django.doj

lsoto: and what about robustapply?

fijal: I'm using a workaround

lsoto: like what?

do you need to modify django for that or not?

like the one posted by anto on the django trac

ok, so it's django modification

but I think I'm going to focus on testing jdunk's new signal code on jython

do you think it'll go into the release?

it's on the maybe list

I know

that's a bit unfortunate, since robustapply patch is "won't fix"

nah -- I'm sure that if the new signal code doesn't go on the release, the anto patch could be brought back and applied for 1.0

I take the wontfix as a signal for us: lets focus on the new signal code, so it is more likely that it goes on the release and fixes everyone's problems :)

well

it's a bit different scale, isn't it?

how so?

lsoto: robustapply patch is changing few lines

signal refactoring is changing bunch of files

that's a bit different in scale

yeah, I get it

BTW, that's the only patch you need to run django on pypy?

yop

I'll check in few minutes if signal refactoring patch works

cool

this also if you have pysqlite3 installed

(but reasons why are pretty obscure)

lsoto: Hi. re: db backend features refactoring, I see adrian applied my patch from #7420

cramm: oops, so I have some merging work to do :(

cramm: do you prefer the approarch of having "date_field_supports_time_value" and "supports_usecs" rather than the delegation of type-conversion to the database backend?

BTW, I'm not pursuing delegating all the type conversion to the backend, I think we can expect that every sane adapter will support strings, ints, longs and booleans

dates, times, datetimes and decimal are another thing :(

lsoto: no, I think your proposal is much better

as in more comprehensive

cool, just thinking that I could be failing to see that something was wrong with it

what's holding me to upload the patch is some test failures related to BaseModel.save_base(raw=True)

errr -- I mean Model.save_base

lsoto: no, signal refactoring does not make it work under pypy

which might mean that jython is not doing well as well

it does not even work under cpython

oops

fijal: how does it fail?

weeeeeel

this kind of means that robustapply patch is even more valid

any insights?

believe me, I can feel your pain, but somehow I got used to work with a patched django

why is so important to get that patched on trunk right now?

lsoto: no, it's important to get that patched before release

and I don't like when someone points me to non-working patch instead of mine which at least works

doesn't improve stuff, but doesn't break either

I'm pretty sure jacobkm *will* apply the patch if the new signal code doesn't make it for the release

so what's wrong with applying it now?

I even wrote a test to prove that it works

it is better to give attention to the refactoring than applying a patch that fixes something that will go away before a release.

it'll make us both a bit happier at no cost

brosner: I don't understand refactoring. It does stuff (a lot). It's broken. It comes without unittests

ok? then help fix it :)

no, it has some test

but it changes behavior

it way bigger decision

than simply fixing stuff without changing anything

then if the decision is made that signal refactoring can't go in before 1.0 then i am sure like lsoto said the other patch will be committed

brosner: can I then reopen a ticket, add it to release and say "don't close unless you commit the other one"?

it is probably to mention it in some notes about vm compatibility

*probably better

I just don't want this issue to slip through

i don't want to call the shots on those tickets since i am not one that is working on that ;)