Hello folks!
I'm in the process of doing the so-called “result-value split”,
i.e. introducing a new xmms_value_t type dissociated from the current
xmmsc_result_t used everywhere. In the new version, result notifiers
are passed a value_t instead of a result_t (the function return value
is used to
Sébastien Cevey wrote:
Hello folks!
Hello!
[here was a nice high level motivation description]
Here follows some quick comments.
Here is my proposed API, strongly based on anders' ideas:
/* Prototypes */
xmms_value_list_t * xmms_value_list_get_iterator (xmms_value_t *val);
int xmms_
Selon Anders Waldenborg <[EMAIL PROTECTED]>:
> I think I would s/xmms_value_list/xmms_value_iter/
Since we will probably have different iterators for lists, dicts and propdicts,
you need to reflect that in the type name too. Initially I had
xmms_value_list_iter_t, but I thought it was too long..
Sebastien Cevey wrote:
Selon Anders Waldenborg <[EMAIL PROTECTED]>:
Selon! Selon!
I think I would s/xmms_value_list/xmms_value_iter/
Since we will probably have different iterators for lists, dicts and propdicts,
you need to reflect that in the type name too. Initially I had
xmms_value_li
Dear List,
I have also done some drafting some day ago and came up with this:
/* Node of the doubly-linked-list of list, dict and propdict */
typedef struct xmms_generic_iterator_St {
xmms_generic_iterator_t *prev;
xmms_generic_iterator_t *next;
xmms_generic_iterator_head_
theefer forgot to cc list.
--- Begin Message ---
Enligt Anders Waldenborg <[EMAIL PROTECTED]>:
> I really want _iter_ in the name..
Ok.
> Also, is it xmms_ or xmmsc_? Maybe it is a entirely new system:
> "xmmsv_", which gives:
v(alue) doesn't seem to live in the same "namespace" as c(lient)
Enligt Anders Waldenborg <[EMAIL PROTECTED]>:
> I really want _iter_ in the name..
Ok.
> Also, is it xmms_ or xmmsc_? Maybe it is a entirely new system:
> "xmmsv_", which gives:
v(alue) doesn't seem to live in the same "namespace" as c(lient) or (server).
mh
and we have xmmsc_coll_t, also used
Sorry for the dupe, I thought anders' didn't forward it.
Selon Sebastien Cevey <[EMAIL PROTECTED]>:
> > x_list_t is bi-directional no? I would not mind making it circular.
>
> No, it isn't (currently).
Don't listen to me, I'm lying. It is, as nesciens' said.
--
Sebastien Cevey - inso.cc
--
Erik Massop wrote:
Currently dict are ...-key-value-key-value-... lists and propdict
...-source-key-value-source-key-value-... lists, so they can be quite
related to lists, if you keep up this linear design. Performancewise
binary-trees or hash-tables might be better.
Just a quick note before I
Sebastien Cevey wrote:
xmmsv_t
xmmsv_coll_t
xmmsv_list_iter_t
Yeah, this also gives nice short names. I think that is the way to go.
[]
Sure I agree with that. The question is what happens to the state of the
internal pointer. With:
def append(v, entry):
it = v.iter()
it.l
On Tue, 24 Jun 2008 16:36:05 +0200
Anders Waldenborg <[EMAIL PROTECTED]> wrote:
> Erik Massop wrote:
> > Currently dict are ...-key-value-key-value-... lists and propdict
> > ...-source-key-value-source-key-value-... lists, so they can be quite
> > related to lists, if you keep up this linear desi
On Tue, 24 Jun 2008 16:56:51 +0200
Anders Waldenborg <[EMAIL PROTECTED]> wrote:
> I was thinking along these lines:
>
> key = xmmsv_new_string("artist")
> val = xmmsv_new_string("Metallica")
> entry=xmmsv_new_pair(key,val)
> list_append(list,entry)
Would key really be an xmmsv_value_t, as that mi
On Tue, Jun 24, 2008 at 4:29 PM, Sebastien Cevey <[EMAIL PROTECTED]> wrote:
> int callback (xmms_value_t *val) {
>iter = xmms_value_get_list_iterator (val); /* allocates */
>
>/* do stuff */
>
>xmms_value_unref (val);
>xmms_value_iter_unref (iter);
> }
What's the reason we don't
Erik Massop wrote:
I was thinking along these lines:
key = xmmsv_new_string("artist") val =
xmmsv_new_string("Metallica") entry=xmmsv_new_pair(key,val)
list_append(list,entry)
Would key really be an xmmsv_value_t, as that might disallows
bindings to convert dicts to the native hash-tables, un
Daniel Svensson wrote:
int callback (xmms_value_t *val) {
iter = xmms_value_get_list_iterator (val); /* allocates */
/* do stuff */
xmms_value_unref (val);
xmms_value_iter_unref (iter);
}
What's the reason we don't do like this:
None. Callee should always borrow the callers re
At Tue, 24 Jun 2008 17:17:22 +0200, Daniel Svensson wrote:
> What's the reason we don't do like this:
Sorry, I think that's already the way I implemented it actually.
--
Sébastien Cevey / inso.cc
" A designer knows he has achieved perfection not when there is nothing
left to add, but when th
At Tue, 24 Jun 2008 18:17:15 +0200, Anders Waldenborg wrote:
> Are you thinking about some specific language?
e.g. in Ruby, we currently use symbols as dict keys. KISS.
> Also just because xmmsv allows you to do strange things doesn't mean
> you have to :)
I don't see why we should allow to do
Sébastien Cevey wrote:
Hello folks!
Hi, theefer!
I'm in the process of doing the so-called “result-value split”,
i.e. introducing a new xmms_value_t type dissociated from the current
xmmsc_result_t used everywhere. In the new version, result notifiers
are passed a value_t instead of a result
Oh, see, I should have read one more email. nesciens' proposal seems
similar to my code.
Erik Massop wrote:
Some notes:
a) I have no clue about the proper names of the types. (Maybe (probably) these
shouldn't even be called iterators!)
b) x_list is not used.
c) key and source are in the iterat
Erik Massop wrote:
On Tue, 24 Jun 2008 16:56:51 +0200
Anders Waldenborg <[EMAIL PROTECTED]> wrote:
I was thinking along these lines:
key = xmmsv_new_string("artist")
val = xmmsv_new_string("Metallica")
entry=xmmsv_new_pair(key,val)
list_append(list,entry)
Would key really be an xmmsv_value_t,
Sébastien Cevey wrote:
At Tue, 24 Jun 2008 18:17:15 +0200, Anders Waldenborg wrote:
Are you thinking about some specific language?
e.g. in Ruby, we currently use symbols as dict keys. KISS.
In Ruby, we use Objects (any type) ;) But I wouldn't advocate that.
irb(main):001:0> {Object.new =>
Selon Erik Massop <[EMAIL PROTECTED]>:
> /* Node of the doubly-linked-list of list, dict and propdict */
> typedef struct xmms_generic_iterator_St {
> xmms_generic_iterator_t *prev;
> xmms_generic_iterator_t *next;
> xmms_generic_iterator_head_t *parent;
>
> xmms_val
On Tue, 24 Jun 2008 23:10:56 -0400
Daniel Chokola <[EMAIL PROTECTED]> wrote:
> > i) IMHO xmms_generic_iterator_head_t should really be in the union (the
> > generic pointer would probably have to be removed)
>
> See how I arranged my list code. The head is the only thing users get to
> touch, wh
On Wed, 25 Jun 2008 09:23:35 +0200
Sebastien Cevey <[EMAIL PROTECTED]> wrote:
> Selon Erik Massop <[EMAIL PROTECTED]>:
>
> > /* Node of the doubly-linked-list of list, dict and propdict */
> > typedef struct xmms_generic_iterator_St {
> > xmms_generic_iterator_t *prev;
> > xmms_generic_it
On Wed, 25 Jun 2008 10:27:10 +0200
Erik Massop <[EMAIL PROTECTED]> wrote:
> /* Repetitive */
Too much so apparently...
> static void xmmsv_generic_iter_remove (xmmsv_generic_iter_t *it) {
> it->prev->next = it->next;
> it->next->prev = it->prev;
>
> free (it);
> }
> /* FIXME: r
Please be on IRC if you're online ;-P
We've just discussed with anders and puzzles and we believe we can get rid of
propdicts if we translate the source_prefs on the server anyway (which is the
plan). It would still be possible to retrieve [source, key, value] tuples, but
because we don't emulate
On Wed, Jun 25, 2008 at 11:27:57AM +0200, Sebastien Cevey wrote:
> your magic cluster thing?
I love magic cluster things!
//Peter
--
___
Xmms2-devel mailing list
Xmms2-devel@lists.xmms.se
http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
Erik Massop wrote:
On Tue, 24 Jun 2008 23:10:56 -0400
Daniel Chokola <[EMAIL PROTECTED]> wrote:
i) IMHO xmms_generic_iterator_head_t should really be in the union (the generic
pointer would probably have to be removed)
See how I arranged my list code. The head is the only thing users get to
to
At Fri, 27 Jun 2008 02:34:22 -0400, Daniel Chokola wrote:
> But supposedly dicts and propdicts merge if we move source preference to
> the client side.
*server* side.
> I really wish someone would show me an example, because I'm not
> understanding how this works. :(
medialib_set_source_pref
29 matches
Mail list logo
