bme-develop

Re: [bme-develop] emoticon code in cvs

[Sir M. <obe...@ho...>]

Hi guys!,

>You only commited Bme.proj, iconprefs.txt and constats.h
>If you wanted to commit the StringTokenizer an IconManger code you
>first have to add to the repository and the do the commit.
>
They should be in the repository now...hope it worked :D

>Look into the MsnList class, there is something for sorting the
>BOutlineList.
>It would be something like this to sort a list.
>	static int	cmpListItem(void*,void*);  //It has to be static.
>	int  (*ptrSort) (void*,void*);
>	ptrSort = cmpListItem;
>	...
>	list- >SortItems(ptrSort);
>
Yes I already looked at that code, but didn't understand it....what doest 
this mean? int  (*ptrSort) (void*,void*); anyway changing the comparison 
method to static did the trick...

regards,

Tim

_________________________________________________________________
MSN Search, for accurate results! http://search.msn.nl

Re: [bme-develop] emoticon code in cvs

[Sir M. <obe...@ho...>]

Hi,

>had to change line 55 in IconManager.cpp, from:
>BBitmap *emoticon = manager->findEmoticon(&subString);
>to
>Emoticon *emoticon = manager->findEmoticon(&subString);
>
Right!  my fault!!! I changed the code...and didn't compile all 
files....anyway if you pass ":D" it should return a smiling emoticon in the 
emoticon structure....but I haven't tested this yet! I will continue on the 
code this week and hope I will have it finished...one problem though! I'm 
expecting major program crashes because of simultanious accessing  the 
BList(via a pointer passed in the message) and the Emoticon structure....I 
think simultanious methods calls will cause that...so we have to test for 
that....I have a solution for the Emoticon Structure....archiving it into 
the message(yeah I know that would increase the memory usage...but if it 
isn't possible in another way...)....the BList of emoticons will be a 
problem though...since a BList can't be archived...:S any suggestions?

>Haven't really looked at the code yet.
Also it it isn't finished yet :D

regards,

Tim

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: [bme-develop] emoticon code in cvs

[Simon T. <sim...@ga...>]

> Hi,
> 
> >had to change line 55 in IconManager.cpp, from:
> >BBitmap *emoticon = manager->findEmoticon(&subString);
> >to
> >Emoticon *emoticon = manager->findEmoticon(&subString);
> >
> Right!  my fault!!! I changed the code...and didn't compile all 
> files....anyway if you pass ":D" it should return a smiling emoticon 
> in the 
> emoticon structure....but I haven't tested this yet! I will continue 
> on the 
> code this week and hope I will have it finished...one problem though! 
> I'm 
> expecting major program crashes because of simultanious accessing  
> the 
> BList(via a pointer passed in the message) and the Emoticon 
> structure....I 
> think simultanious methods calls will cause that...so we have to test 
> for 
> that....I have a solution for the Emoticon Structure....archiving it 
> into 
> the message(yeah I know that would increase the memory usage...but if 
> it 
> isn't possible in another way...)....the BList of emoticons will be a 
> problem though...since a BList can't be archived...:S any 
> suggestions?

Had a bit more of a chance to look at the code. I'm a little confused 
by the ownership model - for example the IconManager gets deleted in 
the destructor of the IconHandler; but gets constructed somewhere else. 
Any reason why this can't be created by the IconHandler? Same for some 
other bits.

Hmm the BList shouldn't chage after it's been loaded right? I can't see 
why there would be a problem with 2 threads accessing the list at the 
same time (as long as they use different pointers, owned by the threads 
themselves). Saying that, I don't think you should call BList methods 
from other threads, but providing the BList doesn;t change, you should 
be able to pass the pointer returned by BList::Items() along with the 
number of items returned by BList::CountItems().

I'm know very little about multithreaded issues though, so I may be 
wrong.

> >Haven't really looked at the code yet.
> Also it it isn't finished yet :D

lol

> regards,
> 
> Tim

Simon

Re: [bme-develop] emoticon code in cvs

[Daniel G. <al7...@ma...>]

Hello

> > I'm 
> > expecting major program crashes because of simultanious accessing 
> > the
> > BList(via a pointer passed in the message) and the Emoticon
> > structure....I
> > think simultanious methods calls will cause that...so we have to 
> > test
> > for
> > that....I have a solution for the Emoticon Structure....archiving 
> > it
> > into
> > the message(yeah I know that would increase the memory usage...but 
> > if
> > it
> > isn't possible in another way...)....the BList of emoticons will be 
> > a
> > problem though...since a BList can't be archived...:S any 
> > suggestions?
>  
> Hmm the BList shouldn't chage after it's been loaded right? I can't 
> see 
> why there would be a problem with 2 threads accessing the list at the 
> same time (as long as they use different pointers, owned by the 
> threads 
> themselves). Saying that, I don't think you should call BList methods 
> from other threads, but providing the BList doesn;t change, you 
> should 
> be able to pass the pointer returned by BList::Items() along with the 
> number of items returned by BList::CountItems().
> 
> I'm know very little about multithreaded issues though, so I may be 
> wrong.
> 
I agree with Simon, there should be no problem sending pointers to 
Emoticons or to the BList. Actually that is how the MsnBuddy and 
MsnList work. Everywhere I need a MsnBuddy object for something I 
request it to the MsnList through the Common::getMsnBuddy(cont char*
,BHandler) method and it returns a pointer to the MsnBuddy object. You 
would only see problems if a particular object holds some kind of 
internal state, where multiple/simultaneous calls would cause the 
internal state to misbehave. I am not sure if the BLists hold any 
internal state, but that would be something you would find in the 
BeBook, so I am guessing BLists are multithreading safe, the problem 
would be the BString objects, where the BeBook warns about it not being 
multithreading safe. I think it would be ok as long as you don't modify 
the contents of the BString from different threads. Maybe limit the 
Emoticons public access to the BStrings.

Regards,
Daniel

Re: [bme-develop] emoticon code in cvs

[Simon T. <sim...@ga...>]

> Hello
> 
> > > I'm 
> > > expecting major program crashes because of simultanious accessing 
> > > the
> > > BList(via a pointer passed in the message) and the Emoticon
> > > structure....I
> > > think simultanious methods calls will cause that...so we have to 
> > > test
> > > for
> > > that....I have a solution for the Emoticon Structure....archiving 
> > > it
> > > into
> > > the message(yeah I know that would increase the memory 
> > > usage...but 
> > > if
> > > it
> > > isn't possible in another way...)....the BList of emoticons will 
> > > be 
> > > a
> > > problem though...since a BList can't be archived...:S any 
> > > suggestions?
> >  
> > Hmm the BList shouldn't chage after it's been loaded right? I can't 
> > see 
> > why there would be a problem with 2 threads accessing the list at 
> > the 
> > same time (as long as they use different pointers, owned by the 
> > threads 
> > themselves). Saying that, I don't think you should call BList 
> > methods 
> > from other threads, but providing the BList doesn;t change, you 
> > should 
> > be able to pass the pointer returned by BList::Items() along with 
> > the 
> > number of items returned by BList::CountItems().
> > 
> > I'm know very little about multithreaded issues though, so I may be 
> > wrong.
> > 
> I agree with Simon, there should be no problem sending pointers to 
> Emoticons or to the BList. Actually that is how the MsnBuddy and 
> MsnList work. Everywhere I need a MsnBuddy object for something I 
> request it to the MsnList through the Common::getMsnBuddy(cont char*
> ,BHandler) method and it returns a pointer to the MsnBuddy object. 
> You 
> would only see problems if a particular object holds some kind of 
> internal state, where multiple/simultaneous calls would cause the 
> internal state to misbehave. I am not sure if the BLists hold any 
> internal state, but that would be something you would find in the 
> BeBook, so I am guessing BLists are multithreading safe, the problem 
> would be the BString objects, where the BeBook warns about it not 
> being 
> multithreading safe. I think it would be ok as long as you don't 
> modify 
> the contents of the BString from different threads. Maybe limit the 
> Emoticons public access to the BStrings.

I'm not sure BLists are thread-safe for write operations (maybe that's 
why the user with the fast connection experienced a crash on logging 
in?). Passing a pointer to the actual list of items along with the the 
number of items should be fine for reading though.

> Regards,
> Daniel

Simon

Re: [bme-develop] emoticon code in cvs

[Sir M. <obe...@ho...>]

Hi,

> > You
> > would only see problems if a particular object holds some kind of
> > internal state, where multiple/simultaneous calls would cause the
> > internal state to misbehave. I am not sure if the BLists hold any
> > internal state, but that would be something you would find in the
> > BeBook, so I am guessing BLists are multithreading safe, the problem
> > would be the BString objects, where the BeBook warns about it not
> > being
> > multithreading safe. I think it would be ok as long as you don't
> > modify
> > the contents of the BString from different threads. Maybe limit the
> > Emoticons public access to the BStrings.
>
>I'm not sure BLists are thread-safe for write operations (maybe that's
>why the user with the fast connection experienced a crash on logging
>in?). Passing a pointer to the actual list of items along with the the
>number of items should be fine for reading though.
>
My thought about the multi threading issues is as follows: if you have a 
pointer to an object it is possible that a method of an object say Items() 
is called twice a the same moment resulting in a crash....(at least that's 
why you have to synchronize methods in java....to prevent the method from 
being called twice a the same moment)....If BeOS does handle this calling 
fine, we are allright...because the BList and the Emoticon objects in it are 
online loaded once! then they aren't changed anymore....

btw Simon you're right about the IconManager/IconHandler stuff....I did this 
for this reason: the list loaded by IconLoader should be passed to the 
IconManager, which will be passed to the IconHandler....but I can also make 
it more safe(in deleting) to pass the List to the Handler and construct the 
IconManager  in the handler, I will change it!

regards,
Tim

_________________________________________________________________
MSN Search, for accurate results! http://search.msn.nl

Re: [bme-develop] emoticon code in cvs

[Simon T. <sim...@ga...>]

> Hi,
> 
> > > You
> > > would only see problems if a particular object holds some kind of
> > > internal state, where multiple/simultaneous calls would cause the
> > > internal state to misbehave. I am not sure if the BLists hold any
> > > internal state, but that would be something you would find in the
> > > BeBook, so I am guessing BLists are multithreading safe, the 
> > > problem
> > > would be the BString objects, where the BeBook warns about it not
> > > being
> > > multithreading safe. I think it would be ok as long as you don't
> > > modify
> > > the contents of the BString from different threads. Maybe limit 
> > > the
> > > Emoticons public access to the BStrings.
> >
> >I'm not sure BLists are thread-safe for write operations (maybe 
> > that's
> >why the user with the fast connection experienced a crash on logging
> >in?). Passing a pointer to the actual list of items along with the 
> > the
> >number of items should be fine for reading though.
> >
> My thought about the multi threading issues is as follows: if you 
> have a 
> pointer to an object it is possible that a method of an object say 
> Items() 
> is called twice a the same moment resulting in a crash....(at least 
> that's 
> why you have to synchronize methods in java....to prevent the method 
> from 
> being called twice a the same moment)....If BeOS does handle this 
> calling 
> fine, we are allright...because the BList and the Emoticon objects in 
> it are 
> online loaded once! then they aren't changed anymore....

Yes, I wouldn't call methods from different threads. However instead of 
passing a pointer to the List itself, pass a pointer to the actual data 
(can be obtained from BList::Items()) along with the number of items. 
Then each thread will have their own independent pointer to the data, 
and providing the actual list data is not changed, they can both read 
the actual items in the list at the same time.

Otherwise you can use a semaphore to make sure only one thread accesses 
the BList at any time (see the kernel kit documentation in the BeBook). 
However, the first solution is better IMHO, as we know that the data 
won't change after it's loaded.

> btw Simon you're right about the IconManager/IconHandler stuff....I 
> did this 
> for this reason: the list loaded by IconLoader should be passed to 
> the 
> IconManager, which will be passed to the IconHandler....but I can 
> also make 
> it more safe(in deleting) to pass the List to the Handler and 
> construct the 
> IconManager  in the handler, I will change it!

I would have the IconHandler deal with everything. So in the main bme 
code we just need
iconHandler = new IconHandler();
and then the icon handler constructor takes care of creating the other 
classes it needs, creating a list of emoticons, populating it, managing 
the list, etc.

> regards,
> Tim

Simon

Re: [bme-develop] emoticon code in cvs

[Sir M. <obe...@ho...>]

Hi,

>Yes, I wouldn't call methods from different threads. However instead of
>passing a pointer to the List itself, pass a pointer to the actual data
>(can be obtained from BList::Items()) along with the number of items.
>Then each thread will have their own independent pointer to the data,
>and providing the actual list data is not changed, they can both read
>the actual items in the list at the same time.
>
Ah right, I'll pass a pointer to the Items them...we probably only need this 
list in the emoticon choosing view(the emoticon matrix) in the chat window 
right?

>I would have the IconHandler deal with everything. So in the main bme
>code we just need
>iconHandler = new IconHandler();
>and then the icon handler constructor takes care of creating the other
>classes it needs, creating a list of emoticons, populating it, managing
>the list, etc.
>
Mmm, problem I have with this approach is that the Handler will be loading 
the icon's...a task it should do....we also can't separate the loading of 
the icons and the starting of the handler, which maybe necessary!

regards,

Tim

_________________________________________________________________
MSN Search, for accurate results! http://search.msn.nl

Re: [bme-develop] emoticon code in cvs

[Simon T. <sim...@ga...>]

> Hi,
> 
> >Yes, I wouldn't call methods from different threads. However instead 
> > of
> >passing a pointer to the List itself, pass a pointer to the actual 
> > data
> >(can be obtained from BList::Items()) along with the number of 
> > items.
> >Then each thread will have their own independent pointer to the 
> > data,
> >and providing the actual list data is not changed, they can both 
> > read
> >the actual items in the list at the same time.
> >
> Ah right, I'll pass a pointer to the Items them...we probably only 
> need this 
> list in the emoticon choosing view(the emoticon matrix) in the chat 
> window 
> right?

Yeh, can't think of anywhere else that would need it.

> >I would have the IconHandler deal with everything. So in the main 
> > bme
> >code we just need
> >iconHandler = new IconHandler();
> >and then the icon handler constructor takes care of creating the 
> > other
> >classes it needs, creating a list of emoticons, populating it, 
> > managing
> >the list, etc.
> >
> Mmm, problem I have with this approach is that the Handler will be 
> loading 
> the icon's...a task it should do....we also can't separate the 
> loading of 
> the icons and the starting of the handler, which maybe necessary!

Well the handler could create an IconLoader in its constructor. All of 
that will be done before any messages are processed anyway.

Why would we want to seperate the loading of the icons from having a 
handler? That would mean we would have all the emoticons loaded in 
memory, but no way of doing anything with them??

> regards,
> 
> Tim

Simon

Re: [bme-develop] emoticon code in cvs

[Daniel G. <al7...@ma...>]

Hi
 
> >Look into the MsnList class, there is something for sorting the
> >BOutlineList.
> >It would be something like this to sort a list.
> >	static int	cmpListItem(void*,void*);  //It has to be static.
> >	int  (*ptrSort) (void*,void*);
> >	ptrSort = cmpListItem;
> >	...
> >	list- >SortItems(ptrSort);
> >
> Yes I already looked at that code, but didn't understand it....what 
> doest 
> this mean? int  (*ptrSort) (void*,void*); anyway changing the 
> comparison 
> method to static did the trick...
> 
Essentially it's how to declare a pointer to a function, a function 
pointer in c++;
type (*pointer) (type parameter1, type paramaeter2, ...);

Daniel

Re: [bme-develop] emoticon code in cvs

[Simon T. <sim...@ga...>]

> Hi guys!,
> 
> >You only commited Bme.proj, iconprefs.txt and constats.h
> >If you wanted to commit the StringTokenizer an IconManger code you
> >first have to add to the repository and the do the commit.
> >
> They should be in the repository now...hope it worked :D

Got the files, but it doesn't compile:

had to change line 55 in IconManager.cpp, from:
BBitmap *emoticon = manager->findEmoticon(&subString);
to
Emoticon *emoticon = manager->findEmoticon(&subString);

Haven't really looked at the code yet.