Backgroundrb devel - Jan 2008 - [PATCH] x 2 - Fix for "null pointer exception" when ask_status is called before worker is run, and docfixes

Sorry for attaching patches in emails to the mailing list, but I''m
still
unable to login to Devjavu for Backgroundrb (I''m able to login just
fine for
Merb''s Devjavu and submitted a ticket successfully).
Anyway, I encountered a bug when trying to #ask_status of a worker before
it''s run (or rather, before its result_hash has been set to something).
Not
sure why it''s no longer being initialized to an empty hash (since
http://backgroundrb.devjavu.com/changeset/279). I''ve attached a patch,
defaults_for_packet_master.diff for this.

update_readme.diff attempts to format the README so that it displays better
in HTML and also removes mention of worker tests being generated from the
worker_generator.

Let me know if there''s a better way for me to submit patches!

Cheers,

Chu Yeow
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080109/11cb0823/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update_readme.diff
Type: application/octet-stream
Size: 10804 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080109/11cb0823/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defaults_for_packet_master.diff
Type: application/octet-stream
Size: 1250 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080109/11cb0823/attachment-0003.obj

Hey,

On Jan 9, 2008 11:59 AM, Cheah Chu Yeow <chuyeow at gmail.com>
wrote:
> Sorry for attaching patches in emails to the mailing list, but I''m
still
> unable to login to Devjavu for Backgroundrb (I''m able to login
just fine for
> Merb''s Devjavu and submitted a ticket successfully).
>
>
> Anyway, I encountered a bug when trying to #ask_status of a worker before
> it''s run (or rather, before its result_hash has been set to
something). Not
> sure why it''s no longer being initialized to an empty hash (since
> http://backgroundrb.devjavu.com/changeset/279). I''ve attached a
patch,
> defaults_for_packet_master.diff for this.
>
> update_readme.diff attempts to format the README so that it displays better
> in HTML and also removes mention of worker tests being generated from the
> worker_generator.
>
> Let me know if there''s a better way for me to submit patches!
Its weird that Devjavu is not letting you submit patches. I will try
to follow up on this.

Thanks for the patches and I will have them in trunk asap.



-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org

Thanks!
Hope this will help debug what''s going on with Devjavu: when I login
(it''s
the right password, since if I try an incorrect password it spews an error
message), it redirects back to wherever I came from, but the ''Login |
Register'' links are still showing and I can''t create a new
ticket.

Cheers,

Chu Yeow


On Jan 9, 2008 3:10 PM, hemant <gethemant at gmail.com> wrote:
> Hey,
>
> On Jan 9, 2008 11:59 AM, Cheah Chu Yeow <chuyeow at gmail.com> wrote:
> > Sorry for attaching patches in emails to the mailing list, but
I''m still
> > unable to login to Devjavu for Backgroundrb (I''m able to
login just fine
> for
> > Merb''s Devjavu and submitted a ticket successfully).
> >
> >
> > Anyway, I encountered a bug when trying to #ask_status of a worker
> before
> > it''s run (or rather, before its result_hash has been set to
something).
> Not
> > sure why it''s no longer being initialized to an empty hash
(since
> > http://backgroundrb.devjavu.com/changeset/279). I''ve attached
a patch,
> > defaults_for_packet_master.diff for this.
> >
> > update_readme.diff attempts to format the README so that it displays
> better
> > in HTML and also removes mention of worker tests being generated from
> the
> > worker_generator.
> >
> > Let me know if there''s a better way for me to submit patches!
>
> Its weird that Devjavu is not letting you submit patches. I will try
> to follow up on this.
>
> Thanks for the patches and I will have them in trunk asap.
>
>
>
> --
> Let them talk of their oriental summer climes of everlasting
> conservatories; give me the privilege of making my own summer with my
> own coals.
>
> http://gnufied.org
>


-- 
Chu Yeow
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080109/26278a03/attachment.html

Hi,

On Jan 9, 2008 12:46 PM, Cheah Chu Yeow <chuyeow at gmail.com>
wrote:
> Thanks!
>
> Hope this will help debug what''s going on with Devjavu: when I
login (it''s
> the right password, since if I try an incorrect password it spews an error
> message), it redirects back to wherever I came from, but the
''Login |
> Register'' links are still showing and I can''t create a
new ticket.
Well the issue with result hash is fixed and I have updated 1.0.1
release tag as well as trunk.

I am starting work on Test Cases now. I saw your comment about lack of
test cases and I am working to amend the situation.
Between my office work, other projects, often things go wary. I have
created the infrastructure for testing the plugin and stuff, I will be
glad if you or anyone is willing to help.

I have been a user of BackgrounDRb since Ezra released first version
and followed the development closely. 0.2.1 release although a major
step forward had nasty unresolved bugs because of DRb and Slave
library. You can browse mailing list archives of ruby-talk and
backgroundrb and find that Slave is a glorious hack, but a hack
nonetheless ( Ara himself admits code is quite difficult to follow ).

So Ezra got busy and moved to better and bigger things, he asked if
anyone is willing to work on it and I volunteered. I think, Ezra
handed over the project not because he was overly impressed with my
contribution, but because NO ONE else stepped forward.

After taking up project, I was getting lots of bug reports ( again
mailing list archives is a proof). Now sad thing is, I was not able to
fix them. Why? Because fork(), threads and DRb was just a disaster. I
tried fixing existing stuff, but honestly it was a mess. I had lots of
workers running under heavy load and they would disappear. Whats more,
changes to slave library screwed up the plugin big time.


So, I did what I could do, I wrote an entire network programming
framework, removed threads, removed slave and drb and made a new
release. I am sure, its not been a smooth ride since then and I am
thankful to early adopters. I also perhaps hurried towards 1.0
release, I should kept versioning incremental. But anyways, we had a
programming model, which was totally transparent and simple ( for me
anyways ). I believe simple stuff should be kept simple ( again thanks
to Zed for the tip), so if you or anyone has time to look into
internals of BackgrounDRb, you will find it pretty easy to understand.
On the other hand,

Abstracting network IO in automated testing is hard and that explains
lack of test cases. But I am not defending it, I have been guilty of
it. I can only amend the situation I hope.

On Jan 10, 2008 12:42 AM, hemant <gethemant at gmail.com>
wrote:
> Hi,
>
> On Jan 9, 2008 12:46 PM, Cheah Chu Yeow <chuyeow at gmail.com> wrote:
> > Thanks!
> >
> > Hope this will help debug what''s going on with Devjavu: when
I login (it''s
> > the right password, since if I try an incorrect password it spews an
error
> > message), it redirects back to wherever I came from, but the
''Login |
> > Register'' links are still showing and I can''t create
a new ticket.
>
> Well the issue with result hash is fixed and I have updated 1.0.1
> release tag as well as trunk.
>
> I am starting work on Test Cases now. I saw your comment about lack of
> test cases and I am working to amend the situation.
> Between my office work, other projects, often things go wary. I have
> created the infrastructure for testing the plugin and stuff, I will be
> glad if you or anyone is willing to help.
>
> I have been a user of BackgrounDRb since Ezra released first version
> and followed the development closely. 0.2.1 release although a major
> step forward had nasty unresolved bugs because of DRb and Slave
> library. You can browse mailing list archives of ruby-talk and
> backgroundrb and find that Slave is a glorious hack, but a hack
> nonetheless ( Ara himself admits code is quite difficult to follow ).
>
> So Ezra got busy and moved to better and bigger things, he asked if
> anyone is willing to work on it and I volunteered. I think, Ezra
> handed over the project not because he was overly impressed with my
> contribution, but because NO ONE else stepped forward.
>
> After taking up project, I was getting lots of bug reports ( again
> mailing list archives is a proof). Now sad thing is, I was not able to
> fix them. Why? Because fork(), threads and DRb was just a disaster. I
> tried fixing existing stuff, but honestly it was a mess. I had lots of
> workers running under heavy load and they would disappear. Whats more,
> changes to slave library screwed up the plugin big time.
>
>
> So, I did what I could do, I wrote an entire network programming
> framework, removed threads, removed slave and drb and made a new
> release. I am sure, its not been a smooth ride since then and I am
> thankful to early adopters. I also perhaps hurried towards 1.0
> release, I should kept versioning incremental. But anyways, we had a
> programming model, which was totally transparent and simple ( for me
> anyways ). I believe simple stuff should be kept simple ( again thanks
> to Zed for the tip), so if you or anyone has time to look into
> internals of BackgrounDRb, you will find it pretty easy to understand.
> On the other hand,
Try reading code of drb of slave. I am sure they offer lot more
features, but its turtles all the way down.
>
> Abstracting network IO in automated testing is hard and that explains
> lack of test cases. But I am not defending it, I have been guilty of
> it. I can only amend the situation I hope.
>


-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org

Hey Hemant, thanks for the detailed explanation. First off, let me just say
that I really appreciate you stepping up to take over - I knew how it
happened (Ezra not having time and such). And I think you are referring to
my comment in http://dominiek.com/articles/2008/1/9/wigitize-com-post-digg.
Dominiek (that blogger) also calls you a prick in an earlier blog post which
of course is terribly uncalled for.
I''d like to help out with add testcases (or specs actually, which I
prefer
more in this case since RSpec allows you to do mocking really easily) so
when I do get some time (I spend most of my "Open Source time" on
Rails)
I''ll be sure to chime in with some patches.

Anyway, don''t let it get to you, you''re doing a good job but I
can see that
there''s probably not enough hands helping by contributing back to
BackgrounDRb - a one-man show is not easy!

Cheers,

Chu Yeow



On Jan 10, 2008 3:15 AM, hemant <gethemant at gmail.com> wrote:
> On Jan 10, 2008 12:42 AM, hemant <gethemant at gmail.com> wrote:
> > Hi,
> >
> > On Jan 9, 2008 12:46 PM, Cheah Chu Yeow <chuyeow at gmail.com>
wrote:
> > > Thanks!
> > >
> > > Hope this will help debug what''s going on with Devjavu:
when I login
> (it''s
> > > the right password, since if I try an incorrect password it spews
an
> error
> > > message), it redirects back to wherever I came from, but the
''Login |
> > > Register'' links are still showing and I can''t
create a new ticket.
> >
> > Well the issue with result hash is fixed and I have updated 1.0.1
> > release tag as well as trunk.
> >
> > I am starting work on Test Cases now. I saw your comment about lack of
> > test cases and I am working to amend the situation.
> > Between my office work, other projects, often things go wary. I have
> > created the infrastructure for testing the plugin and stuff, I will be
> > glad if you or anyone is willing to help.
> >
> > I have been a user of BackgrounDRb since Ezra released first version
> > and followed the development closely. 0.2.1 release although a major
> > step forward had nasty unresolved bugs because of DRb and Slave
> > library. You can browse mailing list archives of ruby-talk and
> > backgroundrb and find that Slave is a glorious hack, but a hack
> > nonetheless ( Ara himself admits code is quite difficult to follow ).
> >
> > So Ezra got busy and moved to better and bigger things, he asked if
> > anyone is willing to work on it and I volunteered. I think, Ezra
> > handed over the project not because he was overly impressed with my
> > contribution, but because NO ONE else stepped forward.
> >
> > After taking up project, I was getting lots of bug reports ( again
> > mailing list archives is a proof). Now sad thing is, I was not able to
> > fix them. Why? Because fork(), threads and DRb was just a disaster. I
> > tried fixing existing stuff, but honestly it was a mess. I had lots of
> > workers running under heavy load and they would disappear. Whats more,
> > changes to slave library screwed up the plugin big time.
> >
> >
> > So, I did what I could do, I wrote an entire network programming
> > framework, removed threads, removed slave and drb and made a new
> > release. I am sure, its not been a smooth ride since then and I am
> > thankful to early adopters. I also perhaps hurried towards 1.0
> > release, I should kept versioning incremental. But anyways, we had a
> > programming model, which was totally transparent and simple ( for me
> > anyways ). I believe simple stuff should be kept simple ( again thanks
> > to Zed for the tip), so if you or anyone has time to look into
> > internals of BackgrounDRb, you will find it pretty easy to understand.
> > On the other hand,
>
> Try reading code of drb of slave. I am sure they offer lot more
> features, but its turtles all the way down.
>
> >
> > Abstracting network IO in automated testing is hard and that explains
> > lack of test cases. But I am not defending it, I have been guilty of
> > it. I can only amend the situation I hope.
> >
>
>
>
> --
> Let them talk of their oriental summer climes of everlasting
> conservatories; give me the privilege of making my own summer with my
> own coals.
>
> http://gnufied.org
>


-- 
Chu Yeow
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080110/7d9a2250/attachment.html

Hi Cheah,

On Jan 10, 2008 7:59 AM, Cheah Chu Yeow <chuyeow at gmail.com>
wrote:
> Hey Hemant, thanks for the detailed explanation. First off, let me just say
> that I really appreciate you stepping up to take over - I knew how it
> happened (Ezra not having time and such). And I think you are referring to
> my comment in 
http://dominiek.com/articles/2008/1/9/wigitize-com-post-digg.
> Dominiek (that blogger) also calls you a prick in an earlier blog post
which
> of course is terribly uncalled for.
>
>  I''d like to help out with add testcases (or specs actually, which
I prefer
> more in this case since RSpec allows you to do mocking really easily) so
> when I do get some time (I spend most of my "Open Source time" on
Rails)
> I''ll be sure to chime in with some patches.
>
>  Anyway, don''t let it get to you, you''re doing a good job
but I can see that
> there''s probably not enough hands helping by contributing back to
> BackgrounDRb - a one-man show is not easy!

Thanks man. I prefer Test/Spec because it has worked better than RSpec
for me in past. Test Helpers are written with Test/Spec in mind.
I will be working on this, coming weekend. If you want to help, I will
be available on #backgroundrb on freenode.



-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org