barry-devel — Development discussion mailing list

Re: [Barry-devel] OS7 devices - GetScreenshot not working

[Chris F. <cd...@fo...>]

On Mon, Nov 14, 2011 at 12:49:15PM +0000, Luca Sale wrote:
> I recently got a new Torch 9860 and tried to get a screenshot but the
> result was a not so pretty picture.
> Have you guys tested "bjavaloader screenshot" with any of the new devices?

Hi Luca,

I don't have an OS7 device, so I'm not able to test Barry against it.

But I've included a patch below which changed bjavaloader screenshot into a
raw data capture.  If you could run it and send the resulting data file,
I may be able to add support to Barry... it seems like it is an image format
issue.

Could you also include the following data captures:

	btool -vl

	bjavaloader deviceinfo

Thanks!
- Chris


diff --git a/tools/bjavaloader.cc b/tools/bjavaloader.cc
index 9e927ac..5dee60f 100644
--- a/tools/bjavaloader.cc
+++ b/tools/bjavaloader.cc
@@ -186,8 +186,8 @@ void GetScreenshot(Barry::Mode::JavaLoader *javaloader, const char *filename)
 
 
 	// Convert to BMP format
-	Data bitmap(-1, GetTotalBitmapSize(info));
-	ScreenshotToBitmap(info, image, bitmap);
+//	Data bitmap(-1, GetTotalBitmapSize(info));
+//	ScreenshotToBitmap(info, image, bitmap);
 
 	// Write BMP file
 	FILE *fp = fopen(filename, "wb");
@@ -196,7 +196,8 @@ void GetScreenshot(Barry::Mode::JavaLoader *javaloader, const char *filename)
 	}
 	AutoClose ac(fp);
 
-	fwrite(bitmap.GetData(), bitmap.GetSize(), 1, fp);
+	fwrite(&info, sizeof(info), 1, fp);
+	fwrite(image.GetData(), image.GetSize(), 1, fp);
 }
 
 void SaveModule(Barry::Mode::JavaLoader *javaloader, const char *filename)

Re: [Barry-devel] OS7 devices - GetScreenshot not working

[Nicolas V. <ni...@vi...>]

Le lundi 14 novembre 2011 à 12:49 +0000, Luca Sale a écrit :
> Hey Guys,
> 
> I've been using Barry for a while and I'm very pleased to use my
> penguin and my BlackBerry together. 
> I recently got a new Torch 9860 and tried to get a screenshot but the
> result was a not so pretty picture.
> Have you guys tested "bjavaloader screenshot" with any of the new
> devices? As far as I'm aware the raw data generated is bigger than the
> previous OS due to the resolution.
> 
> I had a play with the source code but I'm not entirely sure whether is
> the CheckSize function to define the header length or something else.
> 
> I'm using the latest git source btw...
> 
> Let me know if this is something you have come across.

If you have a windows installation, you can use javaloader.exe tools.

The syntax is the same that bjavaloader.

And with USBSnoop or others tool, you can sniff USB data and we will be
able to help your.

Regards,

Nicolas

[Barry-devel] OS7 devices - GetScreenshot not working

[Luca S. <me...@lu...>]

Hey Guys,

I've been using Barry for a while and I'm very pleased to use my penguin
and my BlackBerry together.
I recently got a new Torch 9860 and tried to get a screenshot but the
result was a not so pretty picture.
Have you guys tested "bjavaloader screenshot" with any of the new devices?
As far as I'm aware the raw data generated is bigger than the previous OS
due to the resolution.

I had a play with the source code but I'm not entirely sure whether is the
CheckSize function to define the header length or something else.

I'm using the latest git source btw...

Let me know if this is something you have come across.

Cheers,
Luca

P.S. I had the chance to test it with another OS7 device (9900) and the
outcome was the same. The colours are off, resolution of the image is
alright but the margins and the objects are all messed up.

Re: [Barry-devel] Android build support patch

[Chris F. <cd...@fo...>]

On Fri, Nov 11, 2011 at 02:06:24PM +0000, Toby Gray wrote:
> I had to make a small change here to get it working correctly when 
> Init() is called twice. See
> https://github.com/tobygray/barry/commit/d55b5049ba3e9e1a6ce871406e8519c5e7b0346d
> 
> I don't know if you'd pick it up from my github branch when taking the 
> Android fixes, so thought it best to mention it explicitly.

Good catch, thanks!  Merged.

- Chris

Re: [Barry-devel] Android build support patch

[Chris F. <cd...@fo...>]

On Fri, Nov 11, 2011 at 01:06:04PM +0000, Toby Gray wrote:
> Seems fine to me. I've got one small change to make to the Makefile as 
> it's no longer processed by automake which I've done as:
> 
> https://github.com/tobygray/barry/commit/c8a0e02fd876bb90c29922fcd4739e10f1671526

Merged, thanks!

- Chris

Re: [Barry-devel] Android build support patch

[Nicolas <pr...@fr...>]

To do quick...

Use generic header file name (as time.h, config.h...) is quiet
dangerous... We have to use correctly the brackets or the quotes.

#include <...> 
search in the includes dir (toolchains or specified from the gcc options
-I)

#include "..."
search at first in the current directory (where is the .c / .cpp). And
if not found, it uses the includes dir (so like <...>)

So, in barry code... we should write :
#include "time.h"   // and put the header file with the .c / .cpp
or
#include <barry/time.h>

Regards,

Nicolas


Le mercredi 02 novembre 2011 à 15:44 +0000, Toby Gray a écrit :
> On 01/11/11 21:23, Chris Frey wrote: 
> > Can you explain to me the technical reasons for the time.h rename?
> > 
> > I kinda have that in there on purpose, to expose brokenness... and it
> > looks like Android is broken, if this is a problem.  I'm therefore
> > pre-disposed to not like that patch, unless it comes with a reeeeally,
> > reeeeally good reason. :-)
> 
> Yes. The problem comes that the #include <time.h> on Android includes
> itself, which causes compilation to fail as the 'time' function isn't
> specified. The reason for this happening in Android and not on desktop
> Linux appears to be that the Android build system specifies the
> Android system includes using -I to GCC.
> 
> The reason for this is, I suspect, due to the Android NDK tools being
> able to target several different Android versions. Each version has
> different functions present and so the usr/include for that particular
> version is included. So you end up with the following search path
> (with uninteresting includes removed):
> -I/home/tg/src/barry-trees/tobygray/barry/android/jni/barry
> -I/home/tg/Android/NDK/platforms/android-3/arch-arm/usr/include 
> 
> It appears that using the -isystem option to GCC won't help as
> directories in -isystem are always searched after -I and -isystem is
> really just controlling if warnings are displayed (see
> http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html), and my
> attempts at modifying the Android toolchain to do this confirm this.
> 
> I think there are a few options for working around this:
> 1) Rename time.h to barrytime.h as in the original patches, but like
> you say this is a bit nasty.
> 2) Use #include_next <time.h> inside barry/src/time.h to make sure the
> time.h comes from a different search path. This would need to have
> suitable #ifdef guards and configure support for detecting if the cpp
> supports include_next.
> 3) Use #include <../include/time.h> inside barry/src/time.h and ignore
> the fact that it's a hideous hack! It also only works if the system
> headers are in a directory named include.
> 4) Use -iquote instead of -I for the barry headers when building barry
> for Android.
> 
> I went for 4 in the end as it only requires changes to the Android
> build system (see 5f7ec2deb5ef91e0069c286dd58eede286bc378b).
> 
> > Also, instead of the #ifdefs in various non-compatible places in the
> > source code, I'd rather see a platform specific module, maybe android.cc,
> > which gets added optionally during ./configure, where things like
> > stub versions of pthread_cancel() are stored. Also, an iconvandroid.cc,
> > similar to iconvwin.cc, instead of cluttering the main iconv.cc
> > 
> > This way, we get to rely on common APIs in the rest of the code, and
> > the platform specific stuff can get as hairy as it needs to in its own
> > file, and each file is straightforward, without having to run a mental
> > preprocessor while coding.
> > 
> > I seem you've removed the iconv.cc changes in a later patch, so this
> > is just commentary now. :-)
> 
> I was still doing some #ifdefs in configfile.cc for getpwuid*() calls.
> I've done as you suggested in my github branch.
> 
> I've also done a tidy on my github branch to merge the changes which I
> then undid (such as the iconv.cc one and the build script as a shell
> script instead of a Makefile). I'm very impressed by how easy this was
> to do with "git rebase --interactive d7816d80".
> 
> I've added some documentation on building and using Barry for Android,
> which I realised was missing before. Also I've added the Android build
> files to the list of extra distribution files so that they get
> included in the release tarball.
> 
> Finally I apologise for the whitespace changes you've had to make, I
> thought I'd managed to set up my emacs to use the correct indentation
> levels and characters for the Barry coding style, but I evidently
> didn't set it up correctly for all file types.
> 
> What do you think of the changes in the master branch of my github
> repository now?
> 
> Regards,
> 
> Toby
> ------------------------------------------------------------------------------
> RSA&#174; Conference 2012
> Save $700 by Nov 18
> Register now&#33;
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________ Barry-devel mailing list Bar...@li... https://lists.sourceforge.net/lists/listinfo/barry-devel

Re: [Barry-devel] Android build support patch

[Toby G. <tob...@re...>]

On 11/11/11 01:57, Chris Frey wrote:
> The libusb error code patch got me thinking, and I had to change it back,
> for the most part, but I also changed the API of the Init call that
> relied on it, so hopefully this issue is fully solved now.  The
> TranslateErrcode() function is now just a convenience function, which
> it almost was before, and the libusb/system error code separation is
> more consistent.

I had to make a small change here to get it working correctly when 
Init() is called twice. See
https://github.com/tobygray/barry/commit/d55b5049ba3e9e1a6ce871406e8519c5e7b0346d

I don't know if you'd pick it up from my github branch when taking the 
Android fixes, so thought it best to mention it explicitly.

Regards,

Toby

Re: [Barry-devel] Android build support patch

[Toby G. <tob...@re...>]

On 11/11/11 01:57, Chris Frey wrote:
> I'm assuming that you need EXTRA_DIST for the buildtest script?  Or do you
> need it for your own work?

My only reason for doing it as a subdir was so that doing "make 
distclean && make dist" in the root generated tarballs without any 
Android object files or final binaries in them (assuming that adding the 
whole directory into EXTRA_DISTS would pick these up).

However as long as you don't try to build android before bundling up a 
tarball for release then this shouldn't be a problem.

> I just put the whole android directory into the top level EXTRA_DIST,
> with a few other tweaks, and it works for me here.  I don't see that it is
> strictly necessary to have android/ in the subdirs list, so I removed that.
> Let me know if that was a mistake.

Seems fine to me. I've got one small change to make to the Makefile as 
it's no longer processed by automake which I've done as:

https://github.com/tobygray/barry/commit/c8a0e02fd876bb90c29922fcd4739e10f1671526

> The libusb error code patch got me thinking, and I had to change it back,
> for the most part, but I also changed the API of the Init call that
> relied on it, so hopefully this issue is fully solved now.  The
> TranslateErrcode() function is now just a convenience function, which
> it almost was before, and the libusb/system error code separation is
> more consistent.

Looks like a good change to me. I think the separation into a boolean 
and an error code is sensible.

> Since the android/ directory is fairly standalone, I'm considering you as
> its maintainer.  Feel free to push any changes under that directory.
> As long as I don't see something obvious, I plan to just merge it in, since
> I don't have a test system to for it yet, and don't really know if it works
> or not.  If it works for you, I want it included.

Sounds like a sensible plan with me.

> Again, thanks for your work on this!

That's ok, it was a straight forward enough job thanks to how you've 
structured Barry for ease of porting.

Regards,

Toby

Re: [Barry-devel] Android build support patch

[Chris F. <cd...@fo...>]

On Wed, Nov 09, 2011 at 05:13:42PM +0000, Toby Gray wrote:
> On 08/11/11 22:57, Chris Frey wrote:
> > If you can somehow adjust Android's build system to make sure that all 
> > system directories are listed first, and that all Barry headers must 
> > be included via <barry/...>, then this shouldn't be a problem. Is this 
> > possible? 
> 
> Yes, turns out it is possible. Thanks for the suggestion. I've fixed my 
> github branch at git://github.com/tobygray/barry.git to contain your 
> various suggestions and fixes.

Excellent!


> 1) When running make from the top level, make will recurse into the 
> android directory. There are no default targets, but it's possibly a 
> little ugly that you see android mentioned in make output, even when not 
> building for it.

Yeah, if we don't need to recurse into android, that would be best.


> 2) When you do want to build for android you have to cd into 
> barry/android and run "make android-binaries".
> 
> Can you think of a good way of being able to maintain a list of 
> EXTRA_DIST files, yet not have make recurse into an Android directory? 
> Or are you happy with it the way it currently is?

I'm assuming that you need EXTRA_DIST for the buildtest script?  Or do you
need it for your own work?

I just put the whole android directory into the top level EXTRA_DIST,
with a few other tweaks, and it works for me here.  I don't see that it is
strictly necessary to have android/ in the subdirs list, so I removed that.
Let me know if that was a mistake.


I merged/cherry-picked in your android branch (I did a bit of work on it
along the way, so it is out of order compared to yours, sorry)

The libusb error code patch got me thinking, and I had to change it back,
for the most part, but I also changed the API of the Init call that
relied on it, so hopefully this issue is fully solved now.  The
TranslateErrcode() function is now just a convenience function, which
it almost was before, and the libusb/system error code separation is
more consistent.

The rest of the usbwrap code used exceptions for timeouts, and bool return
values for success or failure.  So we don't really need to know the exact
error code, and if we do, then we already know it is an error state, and
TranslateErrcode() can return 0 if it has an "error."  For it, the error
state is success, since it is meant to return error codes anyway.


Since the android/ directory is fairly standalone, I'm considering you as
its maintainer.  Feel free to push any changes under that directory.
As long as I don't see something obvious, I plan to just merge it in, since
I don't have a test system to for it yet, and don't really know if it works
or not.  If it works for you, I want it included.

Again, thanks for your work on this!

- Chris

Re: [Barry-devel] barry

[Chris F. <cd...@fo...>]

On Thu, Nov 10, 2011 at 05:25:13PM -0500, Chris Frey wrote:
> On Wed, Nov 09, 2011 at 04:42:43PM +0100, Straubmeier G?nter wrote:
> > Hello,
> > 
> > how can I install barry to sync with ubuntu and use with my BlackBerry?
> > 
> > I've tried the following,
> > 
> > sudo add-apt-repository ppa:doctormo/barry-snapshot
> > sudo apt-get update
> > sudo apt-get install barry-util opensync-plugin-barry-4x
> 
> Hi,
> 
> You shouldn't have to add your own repository.  The main Ubuntu repositories
> come with Barry already, although it is a bit old.  I don't know why
> Ubuntu is still on 0.15.
> 
> If you want to use 0.17.x, you can download the .deb packages from
> sourceforge.net directly.


Let me correct myself.  I just noticed that Ubuntu only uses the outdated
"1exp7" version of opensync.

So.... that means in order to get syncing working, you need to go with
a build-your-own for now.  I'm working on new repositories for 0.18.x,
to make this much easier, but for now, the best way to do it is this:

0) Install git

1) Grab the binary-meta git tree

	git clone git://repo.or.cz/opensync/binary-meta.git
	git submodule init
	git submodule update

	You may need to do the update step multiple times if you get
	errors, due to repo.or.cz.

2) Uninstall any "1exp7" opensync packages that you have from outdated Ubuntu

	This includes libopensync1exp7 and anything it depends on.

3) Install the massive build dependencies

	Go into the binary-meta/depscripts directory and run the
	./ubuntu-natty.sh script as root.  This installs all the build
	dependencies you'll need to build everything.

	This is just a script that runs apt-get install, as well as
	Barry's dependency list, which also runs apt-get install.
	So you can edit these files to suit your system if you need to.

4) Build binary packages for your system

	Go into the binary-meta root directory and run:

		make debian-all

	You do not need to be root to build these packages.

	The resulting packages will be under the debian/ directory.

5) Install the deb packages of your choice, and enjoy.  You can install either
	opensync 0.2x or 0.4x.

Not all the opensync plugins are supported in binary-meta yet, but file-sync,
evolution2, kdepim (0.2x), and Barry are there, and I consider them
reliable.  Still in development is adkonadi-sync (0.4x), and google-calendar.

If you have questions, please let me know!

- Chris

Re: [Barry-devel] barry

[Chris F. <cd...@fo...>]

On Wed, Nov 09, 2011 at 04:42:43PM +0100, Straubmeier G?nter wrote:
> Hello,
> 
> how can I install barry to sync with ubuntu and use with my BlackBerry?
> 
> I've tried the following,
> 
> sudo add-apt-repository ppa:doctormo/barry-snapshot
> sudo apt-get update
> sudo apt-get install barry-util opensync-plugin-barry-4x

Hi,

You shouldn't have to add your own repository.  The main Ubuntu repositories
come with Barry already, although it is a bit old.  I don't know why
Ubuntu is still on 0.15.

If you want to use 0.17.x, you can download the .deb packages from
sourceforge.net directly.

Hope that helps,
- Chris

Re: [Barry-devel] Android build support patch

[Toby G. <tob...@re...>]

On 08/11/11 22:57, Chris Frey wrote:
> If you can somehow adjust Android's build system to make sure that all 
> system directories are listed first, and that all Barry headers must 
> be included via <barry/...>, then this shouldn't be a problem. Is this 
> possible? 

Yes, turns out it is possible. Thanks for the suggestion. I've fixed my 
github branch at git://github.com/tobygray/barry.git to contain your 
various suggestions and fixes.

The only changes that I'm not entirely sure about now are the use of 
Makefile.am. Currently the various files to include in the distribution 
tarball are specified by using a Makefile.am in the android directory. 
However this has a couple of consequences:

1) When running make from the top level, make will recurse into the 
android directory. There are no default targets, but it's possibly a 
little ugly that you see android mentioned in make output, even when not 
building for it.
2) When you do want to build for android you have to cd into 
barry/android and run "make android-binaries".

Can you think of a good way of being able to maintain a list of 
EXTRA_DIST files, yet not have make recurse into an Android directory? 
Or are you happy with it the way it currently is?

Regards,

Toby

[Barry-devel] barry

[Straubmeier G. <s.g...@on...>]

Hello,

how can I install barry to sync with ubuntu and use with my BlackBerry?

I've tried the following,

sudo add-apt-repository ppa:doctormo/barry-snapshot
sudo apt-get update
sudo apt-get install barry-util opensync-plugin-barry-4x


But it did not work.

Mit freundlichen Grüßen

Guenter Straubmeier

Mozartstraße 5
86666 Burgheim

08432/263447
s.g...@on...

Re: [Barry-devel] Android build support patch

[Chris F. <cd...@fo...>]

On Wed, Nov 02, 2011 at 03:44:00PM +0000, Toby Gray wrote:
> The reason for this is, I suspect, due to the Android NDK tools being 
> able to target several different Android versions. Each version has 
> different functions present and so the usr/include for that particular 
> version is included. So you end up with the following search path (with 
> uninteresting includes removed): 
> -I/home/tg/src/barry-trees/tobygray/barry/android/jni/barry 
> -I/home/tg/Android/NDK/platforms/android-3/arch-arm/usr/include

Thanks Toby for your detailed explanation!

Is there a way to reverse the above includes?  This should fix the problem
as well, since Barry should never be directly in the main include path.

For example, when installed on a system, Barry's copy of time.h is in
the following path:

	/usr/include/barry18/barry/time.h

The -I option for Barry should never be -I/usr/include/barry18/barry but
only -I/usr/include/barry18

When building from source, there is a barry18 symlink which serves this
purpose too.

Any application that needs Barry headers would then include:

	#include <barry/barry.h>

Just including <barry.h> won't work, or shouldn't work, if the include paths
are correct! :-)  This also hides time.h, so that it can only be included
if specified directly as <barry/time.h> or if included as "time.h" from
a header already under barry/.

The above include then indirectly does:

	#include "time.h"

which should look in the same directory that barry/barry.h is in.

This should all hold true when building the library from source as well,
although the include directory hierarchy is done with symlinks instead.

If you can somehow adjust Android's build system to make sure that all
system directories are listed first, and that all Barry headers must
be included via <barry/...>, then this shouldn't be a problem.

Is this possible?



> I've also done a tidy on my github branch to merge the changes which I 
> then undid (such as the iconv.cc one and the build script as a shell 
> script instead of a Makefile). I'm very impressed by how easy this was 
> to do with "git rebase --interactive d7816d80".

Excellent!  I use rebase a lot, too. :-)  It's extremely handy.


> Finally I apologise for the whitespace changes you've had to make, I 
> thought I'd managed to set up my emacs to use the correct indentation 
> levels and characters for the Barry coding style, but I evidently didn't 
> set it up correctly for all file types.

I'm a bit anal about whitespace. :-)  Sometimes git is even more precise
than I am. :-)  Don't worry too much about it, but I do appreciate the
extra care.

- Chris

Re: [Barry-devel] Fedora reported bug...

[Chris F. <cd...@fo...>]

On Tue, Nov 08, 2011 at 09:31:44AM -0700, Nathanael Noblet wrote:
> Hello,
> 
>   I'm a touch busy so haven't dug deeper... However here's a recently
> reported bug against barry.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=752000

Hi Nathanael,

It kinda looks like there was an exception in the destructor for some
reason.  I'm not sure why this happened, because StopStream() is called
explicitly in bjavaloader.cc, but maybe this was due to unwinding from
a different exception.

I've added a patch to fix this potential destructor naughtiness to the
v0.17.2 branch in git.

http://repo.or.cz/w/barry.git/commitdiff/1378ae757f2947577f4e5dbab9cd1d4beddbcdd6

Thanks,
- Chris

[Barry-devel] Fedora reported bug...

[Nathanael N. <nat...@gm...>]

Hello,

  I'm a touch busy so haven't dug deeper... However here's a recently
reported bug against barry.

https://bugzilla.redhat.com/show_bug.cgi?id=752000

Re: [Barry-devel] Writing sms messages through barry library?

[Chris F. <cd...@fo...>]

On Fri, Nov 04, 2011 at 02:21:02AM -0400, Rick Scott wrote:
> I wouldn't say that, unless you have looked at the AT commands that the
> modem supports. SMS messages are generally sent using AT commands. I'm
> not sure if the modem supports the necessary commands ....
> 
> at                                                                                                                        
> OK
> +CMGF=?                                                                                                                 
> +CMGF:
> (0-1)                                                                                                              
>                                                                                                                           
> OK
> 
> So, it appears that the 9900 can, using the modem.

Nice!  Thanks!

- Chris

Re: [Barry-devel] Writing sms messages through barry library?

[Rick S. <rw...@al...>]

On Thu, 2011-11-03 at 17:12 -0400, Chris Frey wrote:
> On Thu, Nov 03, 2011 at 03:00:54PM +0100, thepenguin whisperer wrote:
> > I wonder if there is yet functionality to send text messages through the
> > Barry library.
> > I checked the "feature list" but couldn't find it. So it probably is not
> > there.
> > I wonder how difficult it would be to write this functionality. I have some
> > C++ knowledge but if it is to much work I probably won't do it.
> > Otherwhise I would give it a shot. It would be great if I could
> > receive/send text messages on my desktop.
> 
> Yes, that would be nice. :-)  But it's not currently possible with the
> current version of Barry.

I wouldn't say that, unless you have looked at the AT commands that the
modem supports. SMS messages are generally sent using AT commands. I'm
not sure if the modem supports the necessary commands ....

at                                                                                                                        
OK
+CMGF=?                                                                                                                 
+CMGF:
(0-1)                                                                                                              
                                                                                                                          
OK

So, it appears that the 9900 can, using the modem.

> 
> It is possible to view the existing SMS messages, but to send them, I think
> you'd need an app on the Blackberry side, and talk to it in some manner.
> 
> I believe the database functionality on the BlackBerry side is done
> programmatically.  So if you wrote an SMS app that recorded and also
> read its own database, then you could write a record parser/builder in
> Barry to do the communication.
> 
> The hard part would be writing the SMS side on the BlackBerry, and trying
> to tie into the BlackBerry Messenger service.  I'm not sure that is possible,
> but I'm not a BlackBerry app expert.  The SMS is probably possible, but
> I don't know how closely guarded the BlackBerry Messenger api is.
> 
> Hope that helps,
> - Chris
> 
> 
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel

Re: [Barry-devel] Writing sms messages through barry library?

[Josh K. <jo...@sl...>]

The BlackBerry API is surprisingly open when it comes to messaging. 
Although I haven't made anything that sends an SMS message (I've made 
things that listen to SMS, and also send email), it wouldn't surprise me 
if it's possible. This link suggests it should be possible:

http://docs.blackberry.com/en/developers/deliverables/30946/Messaging_category_1716085_11.jsp

Barry today has the brawchannel utility. With this you could create your 
own custom protocol for sending SMS messages through your app on the BB. 
Here is an example of writing from a BB app to brawchannel running on 
the desktop:

http://git.slashdev.ca/log4bb/tree/src/com/jiggak/log/adapter/UsbAdapter.java

... the reverse, listing in the app for input from brawchannel should be 
pretty straight forward.

On 11-11-03 5:12 PM, Chris Frey wrote:
> On Thu, Nov 03, 2011 at 03:00:54PM +0100, thepenguin whisperer wrote:
>> I wonder if there is yet functionality to send text messages through the
>> Barry library.
>> I checked the "feature list" but couldn't find it. So it probably is not
>> there.
>> I wonder how difficult it would be to write this functionality. I have some
>> C++ knowledge but if it is to much work I probably won't do it.
>> Otherwhise I would give it a shot. It would be great if I could
>> receive/send text messages on my desktop.
> Yes, that would be nice. :-)  But it's not currently possible with the
> current version of Barry.
>
> It is possible to view the existing SMS messages, but to send them, I think
> you'd need an app on the Blackberry side, and talk to it in some manner.
>
> I believe the database functionality on the BlackBerry side is done
> programmatically.  So if you wrote an SMS app that recorded and also
> read its own database, then you could write a record parser/builder in
> Barry to do the communication.
>
> The hard part would be writing the SMS side on the BlackBerry, and trying
> to tie into the BlackBerry Messenger service.  I'm not sure that is possible,
> but I'm not a BlackBerry app expert.  The SMS is probably possible, but
> I don't know how closely guarded the BlackBerry Messenger api is.
>
> Hope that helps,
> - Chris
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel

Re: [Barry-devel] Writing sms messages through barry library?

[Chris F. <cd...@fo...>]

On Thu, Nov 03, 2011 at 03:00:54PM +0100, thepenguin whisperer wrote:
> I wonder if there is yet functionality to send text messages through the
> Barry library.
> I checked the "feature list" but couldn't find it. So it probably is not
> there.
> I wonder how difficult it would be to write this functionality. I have some
> C++ knowledge but if it is to much work I probably won't do it.
> Otherwhise I would give it a shot. It would be great if I could
> receive/send text messages on my desktop.

Yes, that would be nice. :-)  But it's not currently possible with the
current version of Barry.

It is possible to view the existing SMS messages, but to send them, I think
you'd need an app on the Blackberry side, and talk to it in some manner.

I believe the database functionality on the BlackBerry side is done
programmatically.  So if you wrote an SMS app that recorded and also
read its own database, then you could write a record parser/builder in
Barry to do the communication.

The hard part would be writing the SMS side on the BlackBerry, and trying
to tie into the BlackBerry Messenger service.  I'm not sure that is possible,
but I'm not a BlackBerry app expert.  The SMS is probably possible, but
I don't know how closely guarded the BlackBerry Messenger api is.

Hope that helps,
- Chris

[Barry-devel] Writing sms messages through barry library?

[thepenguin w. <th3...@gm...>]

Hi all,

I wonder if there is yet functionality to send text messages through the
Barry library.
I checked the "feature list" but couldn't find it. So it probably is not
there.
I wonder how difficult it would be to write this functionality. I have some
C++ knowledge but if it is to much work I probably won't do it.
Otherwhise I would give it a shot. It would be great if I could
receive/send text messages on my desktop.

PS: I am not subscribed so please keep me in the TO list.

Kind regards

Re: [Barry-devel] Android build support patch

[Toby G. <tob...@re...>]

On 01/11/11 23:14, Chris Frey wrote:
> In looking over the changes, I noticed that Android doesn't support
> pthread_cancel().  A quick web search revealed some fairly logical
> reasons for this:
>
>      http://www.netmite.com/android/mydroid/1.5/bionic/libc/docs/OVERVIEW.TXT
>
> Since Barry only uses this in one place, I made an attempt to avoid
> this dependency, and I think this will work.  It affects the bjdwp
> socket server.
>

Thanks for making that change, it certainly makes the Android porting 
easier.

Regards,

Toby

Re: [Barry-devel] Android build support patch

[Toby G. <tob...@re...>]

On 01/11/11 21:23, Chris Frey wrote:
> Can you explain to me the technical reasons for the time.h rename?
>
> I kinda have that in there on purpose, to expose brokenness... and it
> looks like Android is broken, if this is a problem.  I'm therefore
> pre-disposed to not like that patch, unless it comes with a reeeeally,
> reeeeally good reason. :-)

Yes. The problem comes that the #include <time.h> on Android includes 
itself, which causes compilation to fail as the 'time' function isn't 
specified. The reason for this happening in Android and not on desktop 
Linux appears to be that the Android build system specifies the Android 
system includes using -I to GCC.

The reason for this is, I suspect, due to the Android NDK tools being 
able to target several different Android versions. Each version has 
different functions present and so the usr/include for that particular 
version is included. So you end up with the following search path (with 
uninteresting includes removed): 
-I/home/tg/src/barry-trees/tobygray/barry/android/jni/barry 
-I/home/tg/Android/NDK/platforms/android-3/arch-arm/usr/include

It appears that using the -isystem option to GCC won't help as 
directories in -isystem are always searched after -I and -isystem is 
really just controlling if warnings are displayed (see 
http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html), and my attempts 
at modifying the Android toolchain to do this confirm this.

I think there are a few options for working around this:
1) Rename time.h to barrytime.h as in the original patches, but like you 
say this is a bit nasty.
2) Use #include_next <time.h> inside barry/src/time.h to make sure the 
time.h comes from a different search path. This would need to have 
suitable #ifdef guards and configure support for detecting if the cpp 
supports include_next.
3) Use #include <../include/time.h> inside barry/src/time.h and ignore 
the fact that it's a hideous hack! It also only works if the system 
headers are in a directory named include.
4) Use -iquote instead of -I for the barry headers when building barry 
for Android.

I went for 4 in the end as it only requires changes to the Android build 
system (see 5f7ec2deb5ef91e0069c286dd58eede286bc378b).

> Also, instead of the #ifdefs in various non-compatible places in the
> source code, I'd rather see a platform specific module, maybe android.cc,
> which gets added optionally during ./configure, where things like
> stub versions of pthread_cancel() are stored. Also, an iconvandroid.cc,
> similar to iconvwin.cc, instead of cluttering the main iconv.cc
>
> This way, we get to rely on common APIs in the rest of the code, and
> the platform specific stuff can get as hairy as it needs to in its own
> file, and each file is straightforward, without having to run a mental
> preprocessor while coding.
>
> I seem you've removed the iconv.cc changes in a later patch, so this
> is just commentary now. :-)

I was still doing some #ifdefs in configfile.cc for getpwuid*() calls. 
I've done as you suggested in my github branch.

I've also done a tidy on my github branch to merge the changes which I 
then undid (such as the iconv.cc one and the build script as a shell 
script instead of a Makefile). I'm very impressed by how easy this was 
to do with "git rebase --interactive d7816d80".

I've added some documentation on building and using Barry for Android, 
which I realised was missing before. Also I've added the Android build 
files to the list of extra distribution files so that they get included 
in the release tarball.

Finally I apologise for the whitespace changes you've had to make, I 
thought I'd managed to set up my emacs to use the correct indentation 
levels and characters for the Barry coding style, but I evidently didn't 
set it up correctly for all file types.

What do you think of the changes in the master branch of my github 
repository now?

Regards,

Toby

Re: [Barry-devel] Android build support patch

[Chris F. <cd...@fo...>]

On Tue, Nov 01, 2011 at 01:10:57PM +0000, Toby Gray wrote:
> I've managed to get Barry building and working on Android. Currently 
> it's just libbarry and the tools which only make use of libbarry (e.g. 
> not bjdwp as it uses libbarrydp and libarryjdwp).

In looking over the changes, I noticed that Android doesn't support
pthread_cancel().  A quick web search revealed some fairly logical
reasons for this:

    http://www.netmite.com/android/mydroid/1.5/bionic/libc/docs/OVERVIEW.TXT

Since Barry only uses this in one place, I made an attempt to avoid
this dependency, and I think this will work.  It affects the bjdwp
socket server.

Nicolas, are you able to run a quick test to make sure this doesn't
affect you, when using the debugger?

Thanks!
- Chris

Re: [Barry-devel] Android build support patch

[Chris F. <cd...@fo...>]

On Tue, Nov 01, 2011 at 01:10:57PM +0000, Toby Gray wrote:
> Hi,
> 
> I've managed to get Barry building and working on Android. Currently 
> it's just libbarry and the tools which only make use of libbarry (e.g. 
> not bjdwp as it uses libbarrydp and libarryjdwp).

Very cool! :-)


> Does anyone have any comments, suggestions or improvements?

Can you explain to me the technical reasons for the time.h rename?

I kinda have that in there on purpose, to expose brokenness... and it
looks like Android is broken, if this is a problem.  I'm therefore
pre-disposed to not like that patch, unless it comes with a reeeeally,
reeeeally good reason. :-)

Also, instead of the #ifdefs in various non-compatible places in the
source code, I'd rather see a platform specific module, maybe android.cc,
which gets added optionally during ./configure, where things like
stub versions of pthread_cancel() are stored. Also, an iconvandroid.cc,
similar to iconvwin.cc, instead of cluttering the main iconv.cc

This way, we get to rely on common APIs in the rest of the code, and
the platform specific stuff can get as hairy as it needs to in its own
file, and each file is straightforward, without having to run a mental
preprocessor while coding.

I seem you've removed the iconv.cc changes in a later patch, so this
is just commentary now. :-)

Thanks,
- Chris