retry does not work

[T. Onoma]

thanks matz and thanks guy for chat. continuations work, but still seem clunky. i'll probably pass proc.

have a good day,
-t0

> Hi,
>
> In message "Re: retry does not work"
> on 03/11/20, "T. Onoma" <transami@runbox.com> writes:
>
> |that is a good point, but the alternative seems to be passing proc or passing self. self seems like over kill, but passing proc is messy. no win situation here? perhaps this suggests another facility like raise but that does not halt execution. rather it moves up the call chain looking for a handler, if it finds one it executes, if not forget it, and then resumes execution. better RCR?
>
> It's called "coroutine". If you are going to write new RCR, I
> recommend you to google it first.
>
> matz.
>
>

[Robert Klemme]

"T. Onoma" <transami@runbox.com> schrieb im Newsbeitrag
news:E1AMmpA-000682-J5@odie.runbox.com...

> > You are raising an exception, this is, for me, different than sending
> > message to stdout

>
> okay, i grant you that was not the intention of raise when designed. but

a rose by any other name....

>
> so what other means are there? should a raise_message be added? or maybe

you are right. maybe my library is "badly designed", but if so then tell
me what would the alternative be that achieves such seperation?

class Downloader
attr_accessor :state_reporter

def dowload(url)
read_bytes = 0

# open conn

while( chunk = io.read( 1024 ) )
read_bytes += chunk.length
# write bytes to file
self.state_reporter && self.state_reporter.call(url, read_bytes)
end
end
end

d = Downloader.new
d.state_reporter = proc {|url, bytes| puts "read #{bytes} from #{url}"

d.download 'http://foo/bar'

You get the picture...

robert

[T. Onoma]

robert:

thanks robert, that's basically what i decided to do. your code is nice and clean to. i like that.

but you know. it strikes me as funny that its thought a good idea to implement nested chains of handlers for errors but not for message passing. it seems like a natural fit to me. but when ever i bring it up i get all sorts of nay nays. what so bad about this idea? i think it would be a very powerful tool. i agree that resume should be automatic for this purpose, and a seperate command should exist. i don't what to hurt the poor little raise command. i'm not that bad! ;)

i may try to implement a way to do it.

later,
-t0

>
> "T. Onoma" <transami@runbox.com> schrieb im Newsbeitrag
> news:E1AMmpA-000682-J5@odie.runbox.com...

> > > You are raising an exception, this is, for me, different than sending
> > > message to stdout

> >
> > okay, i grant you that was not the intention of raise when designed. but

> a rose by any other name....

> >
> > so what other means are there? should a raise_message be added? or maybe

> you are right. maybe my library is "badly designed", but if so then tell
> me what would the alternative be that achieves such seperation?
>
> class Downloader
> attr_accessor :state_reporter
>
> def dowload(url)
> read_bytes = 0
>
> # open conn
>
> while( chunk = io.read( 1024 ) )
> read_bytes += chunk.length
> # write bytes to file
> self.state_reporter && self.state_reporter.call(url, read_bytes)
> end
> end
> end
>
> d = Downloader.new
> d.state_reporter = proc {|url, bytes| puts "read #{bytes} from #{url}"
>
> d.download 'http://foo/bar'
>
> You get the picture...
>

>
>
>

[Robert Klemme]

"T. Onoma" <transami@runbox.com> schrieb im Newsbeitrag
news:E1AMoNZ-0006k6-6g@fetch-bak.runbox.com...

> robert:
>
> thanks robert, that's basically what i decided to do. your code is nice

and clean to. i like that.

Thanks!

> but you know. it strikes me as funny that its thought a good idea to

implement nested chains of handlers for errors but not for message
passing.

The pattern usually used for distributing messages is Observer, i.e., you
have some event emitting item and others can register to receive these
events. I'm not sure what your idea of "nested chains of handlers" is
exactly and why it is best suited for this situation.

> it seems like a natural fit to me. but when ever i bring it up i get all

sorts of nay nays. what so bad about this idea? i think it would be a very
powerful tool. i agree that resume should be automatic for this purpose,
and a seperate command should exist. i don't what to hurt the poor little
raise command.

The problem is that you wanted to (ab)use exceptions for this. Exceptions
have a totally different purpose and don't fit well for a notification
mechanism other than exceptional notifications, i.e. situations where the
normal flow of control can't be resumed.

In fact, I don't see any reason to jump *out* of a context just to emit an
event. Instead jumping *into* another context (by issuing a method call)
is perfectly ok. And that's how event distribution typically works.

> i'm not that bad! ;)

Can we trust you on this...? :-)

robert

[Yukihiro Matsumoto]

Hi,

In message "Re: retry does not work"
on 03/11/20, "Robert Klemme" <bob.news@gmx.net> writes:

|> You can use continuation if you
|> want to do something like that.
|
|Isn't that a bit overkill? Hm...

"resume" (or coroutine) requires continuation anyway.

matz.

[Robert Klemme]

"Yukihiro Matsumoto" <matz@ruby-lang.org> schrieb im Newsbeitrag
news:1069362449.622441.23124.nullmailer@picachu.ne tlab.jp...

> Hi,
>
> In message "Re: retry does not work"
> on 03/11/20, "Robert Klemme" <bob.news@gmx.net> writes:
>
> |> You can use continuation if you
> |> want to do something like that.
> |
> |Isn't that a bit overkill? Hm...
>
> "resume" (or coroutine) requires continuation anyway.

Well, yes. It's just that it seems to me that "resume" is not the
appropriate means for signallin status events. That loooks more like
Observer which can be implemented without "resume" and continuations.

Regards

robert

[Yukihiro Matsumoto]

Hi,

In message "Re: retry does not work"
on 03/11/21, "Robert Klemme" <bob.news@gmx.net> writes:

|> "resume" (or coroutine) requires continuation anyway.
|
|Well, yes. It's just that it seems to me that "resume" is not the
|appropriate means for signallin status events. That loooks more like
|Observer which can be implemented without "resume" and continuations.

I don't know. Transami wanted something, which is known as coroutine.
If he really wanted that something, continuation is the best way to
implement it. Maybe it's overkill, or maybe not.

matz.

[T. Onoma]

On Friday 21 November 2003 09:32 am, Robert Klemme wrote:

> Well, yes. It's just that it seems to me that "resume" is not the
> appropriate means for signallin status events. That loooks more like
> Observer which can be implemented without "resume" and continuations.

that's the passing of self method. there is also pass proce method. my resume
continuation method (which does not work) and me betes there's a couple more.
$global.call probably has one in there somewere too. BUT.......

_why has given us better way: singleton methods with ducktyping! IMHO Perfect!

-t0

[Charles Hixson]

T. Onoma wrote:

>Guy:
>
>
>

>>T> ...
>> Then change it : your need of resume in this case...
>>
>>

>
>...i have a user interface script that uses the library. things happen in the library and if the user has set verbose more i should be able to report them to the user ...
>-ts
>

To me it seems that to handle this concern, the proper approach is to
raise the exception within the library, catch it within the library
(actually, within the same routine if possible), if you can't handle it
there, then print out your message and re-raise the exception. Of
course the "printing out of the message" could be handled via a call to
a custom "message handler" routine that serves your needs, so you have
extra place (probably within the library) to specialize things in a more
global way. "resume" is quite tricky if you don't know just where you
will be resuming to (consider what would happen to an external routine
that "resumed" a program structured as I'm proposing). I feel that
resume is normally best used within the same routine that threw the
exception, and that any other use is...dangerous. It is too likely that
later editing will introduce side effects without seeing the problems
that are being caused.