hecl-devel Mailing List for Hecl Programming Language (Page 2)
Brought to you by:
davidw
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(59) |
Apr
(11) |
May
(3) |
Jun
(2) |
Jul
|
Aug
(21) |
Sep
(3) |
Oct
(14) |
Nov
(10) |
Dec
(7) |
2006 |
Jan
(29) |
Feb
(30) |
Mar
(53) |
Apr
(41) |
May
(97) |
Jun
(55) |
Jul
(29) |
Aug
(75) |
Sep
(114) |
Oct
(44) |
Nov
(14) |
Dec
(5) |
2007 |
Jan
(4) |
Feb
(2) |
Mar
(5) |
Apr
(18) |
May
(10) |
Jun
(13) |
Jul
(22) |
Aug
(59) |
Sep
(13) |
Oct
(28) |
Nov
(28) |
Dec
(93) |
2008 |
Jan
(44) |
Feb
(17) |
Mar
(23) |
Apr
(26) |
May
(38) |
Jun
(1) |
Jul
(29) |
Aug
(49) |
Sep
(3) |
Oct
(25) |
Nov
(1) |
Dec
(11) |
2009 |
Jan
(31) |
Feb
(21) |
Mar
(46) |
Apr
(7) |
May
(39) |
Jun
(24) |
Jul
(5) |
Aug
(52) |
Sep
(11) |
Oct
|
Nov
|
Dec
|
From: David W. <dav...@gm...> - 2009-08-19 11:17:48
|
Using the 'barry' tools for Linux, I got Hecl loaded on to an actual BlackBerry device, and it seems to run ok, although the 'form' is definitely ugly... -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: David W. <dav...@gm...> - 2009-08-19 09:51:02
|
> Wolfgang, have you coming back from your vacation? > I would like to ask and discuss about your MIDP 2.0 commands. He's mentioned that he's back, but quite busy - post away to the list. >> I have gone ahead and committed it, but do think it needs some >> modification or at least consideration of various elements. > Please go ahead, tear them apart and make it better. I'm in the process of doing that:-) >> * proc's with :LeadingColons - I don't really see the benefit. You >> know from the structure of Hecl what's a proc: it's always the first >> word in a group. With the :globalvars, it also leads to a few too >> many :'s around for my tastes:-) > > I choose the : prefix to make it doesn't collide with the examples. > First I use __ prefix but they seem so verbose, so I pick another one. I see... To tell the truth, since this is example code that people will potentially use to get started with their own projects, I would rather be a bit verbose, rather than 'convenient to edit on a phone'. >> * Hecl indentation is definitely 4 :-) > > I know, but on the phone 4 space is too much. > Maybe we could make the Canvas based editor and make this a non issue? > Any volunteer? Here's an idea: let's use tabs... hrm... those seem to be more than 4 spaces on my phone. So... that doesn't work. 4 isn't bad on my phone, but I suppose on devices with a bit less space it is not so good. However, I'd still like to go with readability. > Yeah, I'm just trying to test the Hecl limit. I was impressed with what you did in that direction, actually! >> alias /alert lcdui.alert > > In the long run I would like to make the default command short > and to the point, so we don't even need the alias. I think the idea was to avoid conflicts with things like list - lcdui.list. >> * Anonymous commands, which you use ':' for (are you a Forth fan?:-). >> That requires some more experimentation, but it's an interesting >> idea... > > Nah, just trying to pick a short command. > > Here's what I have in mind for Hecl 2.0: > > set form [form title: "Form Title"] > set name [text label: "Name:" text: "Your name here"] > $form append $name > set cmd [cmd label: Greet llabel: "Greeting"] > $form add $cmd { > showmsg "Hello [$name get text:]" > } > $form add [cmd label: Exit llabel: "Exit App"] { > midlet.exit > } > $form show I like it - it actually looks a little bit more like the midp1.0 code I did:-) Did you have a look at that? -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: Zakaria <z4...@gm...> - 2009-08-19 06:59:28
|
A post Google Open Source Blog, show it can be done: http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html On Wed, Aug 19, 2009 at 1:02 PM, Zakaria<z4...@gm...> wrote: > How about a combination of both? > We use Google Code as a point of entry for user: > - Release > - Mailing List > - Wiki > - Bug Tracking > and use github as development repo, so we could all have our own private > branch that you could pull and push. Or maybe we could use Google Code > SVN as a mirror for official branches. > Anybody here an expert in git-svn? > Is it possible to use it like that? > On Tue, Aug 18, 2009 at 4:10 PM, David Welton<dav...@gm...> wrote: >> Hi, > >> I have been thinking a bit about infrastructure for Hecl since my last >> post regarding svn and git. I am thinking that it's nearly time to do >> a bit of housecleaning. -- Zakaria z4...@gm... Yahoo!: z4k4ri4 http://tukangprogram.com http://pemula.linux.or.id |
From: Zakaria <z4...@gm...> - 2009-08-19 06:02:25
|
How about a combination of both? We use Google Code as a point of entry for user: - Release - Mailing List - Wiki - Bug Tracking and use github as development repo, so we could all have our own private branch that you could pull and push. Or maybe we could use Google Code SVN as a mirror for official branches. Anybody here an expert in git-svn? Is it possible to use it like that? On Tue, Aug 18, 2009 at 4:10 PM, David Welton<dav...@gm...> wrote: > Hi, > I have been thinking a bit about infrastructure for Hecl since my last > post regarding svn and git. I am thinking that it's nearly time to do > a bit of housecleaning. > Some possibilities: > * Google Code > * github > * Other? > These relate to the following services: > * version control: svn and git are the two candidates here. git can > import the entire svn history, which I don't want to lose. I'm not > sure if google code can do this... a quick search shows that it's > *possible*, but potentially a pain in the neck. git is a bit harder > to use from windows. Actually, we could also consider Mercurial, as > that's available on Google Code, but I have already invested some time > in git, and it seems 'good enough'. > * bug tracking: both github and google code have this. google code's > looks simpler and cleaner, and everyone has a gmail account, whereas > not everyone has a github account. > * mailing list. Google Groups is definitely the way to go here. It's > a nice, clean interface that is much easier to admin and sign up for > than the SF mailing list. You can choose to interact with it like a > web forum, or as a mailing list. It would be possible to export the > current user list and reimport it in a Google Group. > Other stuff? I hate SF's file release system, and love the idea of > having 'nightly builds' available from Github. A 'marketing' > consideration is that github is new and popular, whereas SF has an > old/tired/ugly image, and while that's not worth the disruption by > itself, it is a consideration. > Thoughts? Questions? > -- > David N. Welton -- Zakaria z4...@gm... Yahoo!: z4k4ri4 http://tukangprogram.com http://pemula.linux.or.id |
From: Pat T. <pat...@go...> - 2009-08-18 14:59:16
|
2009/8/18 David Welton <dav...@gm...>: > > I have been thinking a bit about infrastructure for Hecl since my last > post regarding svn and git. I am thinking that it's nearly time to do > a bit of housecleaning. 'git svn' works pretty well against sites hosted by Google code giving people a choice between svn and git. I would say that git on windows is only going to get better and it is quite usable now (msysGit). The TortoiseGit project is coming along as well. |
From: Neal M. <ne...@bc...> - 2009-08-18 14:18:51
|
Here's just one more pitch for bzr and launchpad. bzr can also import svn trees, and launchpad can host it, or you can host your own. I've used bzr for a while, and git just a bit and I think the user interface is better designed for bzr. Though I love the hashing features of git. Both are far better than svn. Launchpad also does bug tracking and mailing lists, as well as support for blueprints (specifications) for new features, help with translations, suport for answering questions, and an api, and is now mostly released as open source. https://launchpad.net/ Neal McBurnett http://neal.mcburnett.org/ On Tue, Aug 18, 2009 at 11:10:07AM +0200, David Welton wrote: > Hi, > > I have been thinking a bit about infrastructure for Hecl since my last > post regarding svn and git. I am thinking that it's nearly time to do > a bit of housecleaning. > > Some possibilities: > > * Google Code > > * github > > * Other? > > These relate to the following services: > > * version control: svn and git are the two candidates here. git can > import the entire svn history, which I don't want to lose. I'm not > sure if google code can do this... a quick search shows that it's > *possible*, but potentially a pain in the neck. git is a bit harder > to use from windows. Actually, we could also consider Mercurial, as > that's available on Google Code, but I have already invested some time > in git, and it seems 'good enough'. > > * bug tracking: both github and google code have this. google code's > looks simpler and cleaner, and everyone has a gmail account, whereas > not everyone has a github account. > > * mailing list. Google Groups is definitely the way to go here. It's > a nice, clean interface that is much easier to admin and sign up for > than the SF mailing list. You can choose to interact with it like a > web forum, or as a mailing list. It would be possible to export the > current user list and reimport it in a Google Group. > > Other stuff? I hate SF's file release system, and love the idea of > having 'nightly builds' available from Github. A 'marketing' > consideration is that github is new and popular, whereas SF has an > old/tired/ugly image, and while that's not worth the disruption by > itself, it is a consideration. > > Thoughts? Questions? > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > Sent from Padua, Veneto, Italy > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hecl-devel mailing list > Hec...@li... > https://lists.sourceforge.net/lists/listinfo/hecl-devel |
From: David W. <dav...@gm...> - 2009-08-18 09:10:15
|
Hi, I have been thinking a bit about infrastructure for Hecl since my last post regarding svn and git. I am thinking that it's nearly time to do a bit of housecleaning. Some possibilities: * Google Code * github * Other? These relate to the following services: * version control: svn and git are the two candidates here. git can import the entire svn history, which I don't want to lose. I'm not sure if google code can do this... a quick search shows that it's *possible*, but potentially a pain in the neck. git is a bit harder to use from windows. Actually, we could also consider Mercurial, as that's available on Google Code, but I have already invested some time in git, and it seems 'good enough'. * bug tracking: both github and google code have this. google code's looks simpler and cleaner, and everyone has a gmail account, whereas not everyone has a github account. * mailing list. Google Groups is definitely the way to go here. It's a nice, clean interface that is much easier to admin and sign up for than the SF mailing list. You can choose to interact with it like a web forum, or as a mailing list. It would be possible to export the current user list and reimport it in a Google Group. Other stuff? I hate SF's file release system, and love the idea of having 'nightly builds' available from Github. A 'marketing' consideration is that github is new and popular, whereas SF has an old/tired/ugly image, and while that's not worth the disruption by itself, it is a consideration. Thoughts? Questions? -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: David W. <dav...@gm...> - 2009-08-18 08:07:19
|
forwarded with permission ---------- Forwarded message ---------- From: Zakaria <z4...@gm...> Date: Tue, Aug 18, 2009 at 6:26 AM Subject: Re: [Hecl-devel] Any objections to a new release? To: David Welton <dav...@gm...> Oops: > Here's what I have in mind for Hecl 2.0: > > set form [form title: "Form Title"] > set name [text label: "Name:" text: "Your name here"] > $form append $name > set cmd [cmd label: Greet llabel: "Greeting"] > $form add $cmd { global name > showmsg "Hello [$name get text:]" > } > $form add [cmd label: Exit llabel: "Exit App"] { > midlet.exit > } > $form show Anybody has a fix for global proliferation? -- Zakaria z4...@gm... Yahoo!: z4k4ri4 http://tukangprogram.com http://pemula.linux.or.id -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: David W. <dav...@gm...> - 2009-08-18 08:07:12
|
forwarded with permission ---------- Forwarded message ---------- From: Zakaria <z4...@gm...> Date: Tue, Aug 18, 2009 at 6:15 AM Subject: Re: [Hecl-devel] Any objections to a new release? To: David Welton <dav...@gm...> Sorry for late reply, but I just got back from business trip and following that we got long weekend. On Wed, Aug 12, 2009 at 5:31 PM, David Welton<dav...@gm...> wrote: > I think Hecl should definitely include code to make this stuff easy > for people - I don't want to just push the phone mapping stuff down > into people's individual Hecl scripts. I think it will take some > effort, and more research, though. Wolfgang is more of an expert than > I am in terms of running Hecl on a wide variety of phones, hopefully > he will have a moment to comment. Wolfgang, have you coming back from your vacation? I would like to ask and discuss about your MIDP 2.0 commands. > I like your code, and think we can use that as the code that Hecl > ships with. Like the one I did for Android, I like the fact that you > can view the source code and edit it. I also like the creativity. > I have gone ahead and committed it, but do think it needs some > modification or at least consideration of various elements. Please go ahead, tear them apart and make it better. > Hecl, not being widely used, doesn't have a defined style that people > need to use, so that means we're also free to define things as we see > fit. That said, your code is a bit different than most Hecl code I've > seen (or written) so far. That's not necessarily a bad thing, but > since this is going to be *the* example script, it's important that we > talk about it a little bit. In particular: > * The : in front of global variables. Distinguishing them like that > is not a bad idea, but I'm undecided whether I'd use it myself. > * proc's with :LeadingColons - I don't really see the benefit. You > know from the structure of Hecl what's a proc: it's always the first > word in a group. With the :globalvars, it also leads to a few too > many :'s around for my tastes:-) I choose the : prefix to make it doesn't collide with the examples. First I use __ prefix but they seem so verbose, so I pick another one. > * Hecl indentation is definitely 4 :-) I know, but on the phone 4 space is too much. Maybe we could make the Canvas based editor and make this a non issue? Any volunteer? > There are also some things that, while I think they are good Hecl, or > sensible, need some thinking about just because script.hcl has to be > held to a high standard, and is something many people will likely look > at. > * 'Short' names. that's very handy if you're editing the script on > the phone, but less so if someone is looking to grab a bit of example > code and use it in their own script. > * Redefining proc makes things confusing. I think it might make more > sense to create your own command along the lines of AliasProc, and add > a comment that it adds a bunch of aliases. Yeah, I'm just trying to test the Hecl limit. > Lastly, your code suggests a few things that might be interesting to > add to Hecl itself: > * Command aliases. Having short commands to type is nice, but the > mechanism you end up using is a bit circuitous, and would be a lot > easier if you could jsut write: > alias /alert lcdui.alert In the long run I would like to make the default command short and to the point, so we don't even need the alias. > * Anonymous commands, which you use ':' for (are you a Forth fan?:-). > That requires some more experimentation, but it's an interesting > idea... Nah, just trying to pick a short command. Here's what I have in mind for Hecl 2.0: set form [form title: "Form Title"] set name [text label: "Name:" text: "Your name here"] $form append $name set cmd [cmd label: Greet llabel: "Greeting"] $form add $cmd { showmsg "Hello [$name get text:]" } $form add [cmd label: Exit llabel: "Exit App"] { midlet.exit } $form show > -- > David N. Welton -- Zakaria z4...@gm... Yahoo!: z4k4ri4 http://tukangprogram.com http://pemula.linux.or.id -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: David W. <dav...@gm...> - 2009-08-15 22:01:35
|
> * Command aliases. Having short commands to type is nice, but the > mechanism you end up using is a bit circuitous, and would be a lot > easier if you could jsut write: I went ahead and added an 'alias' command, and the cmdAlias method in Interp.java. It's not much code at all, and I can see how it would be happy to provide some short links to commands. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ |
From: David W. <dav...@gm...> - 2009-08-15 12:35:29
|
Wine + the emulator just doesn't quite work all the time, so I backtracked and tried a different approach: Microsoft is allowing free downloads of Windows 7 betas from their web site, which combined with VirtualBox, makes for a very nice Windows sandbox where I got the emulator/BB tools up and running. Compiling works just fine in Linux, but the emulator is definitely faster under Windows (even when Windows itself is being emulated:-). Anyway, the whole process is a big hassle and there are lots of little "gotchas", so if anyone else is trying to set up an environment to hack on BlackBerry stuff, I'd be more than welcome to give a hand. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: David W. <dav...@gm...> - 2009-08-15 12:34:56
|
Hi, As I've mentioned in the past, I am working on making Hecl do as much as possible on BlackBerry devices. In the time I have, I'm going to try and accomplish as much as possible to make Hecl as capable as possible on these devices. In the interests of being open, I have received permission to discuss the priority of which API's to work on with my client/sponsor on this list. I'm sending a *very rough* idea of what might be done in what order, in this Google spreadsheet: https://spreadsheets.google.com/ccc?key=0An76R90VwaRodGJjYnpEOFVUMkVKZVp0akZHZHVZeGc&hl=en The idea is generally to favor communication/interactivity/networking sorts of things, but there's a lot to be done, so we're also open to suggestions of particular device features that would be really cool to access from Hecl. Naturally, the order of what gets worked on may also change depending on the details of how things proceed - one API may require the presence of another, and so on... -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: David W. <da...@de...> - 2009-08-12 14:53:37
|
[ CC'ed to the list ] > very thanks for your reply,and i am sorry that i use a "trashy" word. very > sorry! in fact i am using a translator software. No problem, I supposed that it was an error in translation! > i hava done a Hecl test. the code like this: > set i 0 > while{< $i 10000}{ > incr $i > } > it cost 500MS time on wtk, write the same code in java : > int i=0; > while(i<10000) > i++; > it just cost 4MS time. i think that Hecl maybe is not very fast, so i hope Hecl is certainly much slower than Java! It is interpreted, vs compiled to byte codes that may even be JIT'ed (just in time compiled) on some platforms. You don't want to use Hecl for anything performance intensive. What you could do, though, is create a Hecl command in Java that does performance intensive work: class CountCmd implements Command { public Thing cmdCode(Interp interp, Thing[] argv) throws HeclException { int n = IntThing.get(argv[1]); int i = 0; while (i < n) { i ++; } return argv[1]; } } In other words: don't try and write a fast action game in Hecl - write it in Java, and use Hecl to add make it possible to configure the game, or add new levels or otherwise extend it. > you can improve code run fast. > i suggest Lists: and Hash tables: is maybe not very useful on j2me. j2me is > a lightwidget system. usually j2me command script need not to much featrue. Lists and hashes are pretty important, especially the former, if you ever want to deal with more than one thing. ListThings are also fairly integral to Hecl's functioning. For instance, an error / stack trace is a list of procs (and can be manipulated with the list commands). > i think just these featrues are need: > set > [] > while > for > if > else > call host api > others are not very useful on j2me. so if you hava a simple version of Hecl > i hope you can send it to me. i am very thanks! Uncompressed, for normal Java, Hecllib.jar is only 80K, and that includes some networking code (http). You could probably work on the files in core/ to eliminate what you don't need, but I think you'll find that it's already a fairly minimalistic system. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: David W. <da...@de...> - 2009-08-12 13:55:16
|
Hi, [ You might want to subscribe to the mailing list - I moderated your message through, though ] > hello , i am a j2me developer, i think your Hecl language is a good j2me > script language,i am very intreasting in it. i hava dowanload the Hecl > sourcecode, and try to read it .i found that your Hecl Interp is not very > simple, it has some trashy feature,the Interp is extends Thread, to run a It has grown in complexity over time, but I think it's not that hard to understand once you get the basic idea. This has some details on how Hecl works, internally: http://www.welton.it/articles/hecl_implementation Of course if you have questions on how it works, or think that portions of the source code could use more/better comments, let me know, so that I can improve them. I'm more than happy to help if anyone has questions about some portion of Hecl and how it works. Also, I am on IRC on #hecl at irc.freenode.net (there's even a link from the hecl.org front page) if you want to chat in real time. I am not always there, though... (By the way, "trashy" isn't a good word to use in English) > script need to start a Thread,i think this is not a good idea! because it > may be bring some synchronization problem ,and it is not very fast if you > use two Thead in a MIDlet. on the other hand i think Hecl not hava some The Thread stuff was added so that it would be possible to have an event system in Hecl, and it's also useful for the GUI, and things like the http package, if I recall correctly (without digging in the code) The main thread doesn't actually do much - it sits around waiting for stuff to happen in the GUI, but otherwise doesn't occupy much in terms of resources. > feature, for example i write a Lib for my MIDlet, it has a command > messagebox.show(String message) if call it ,it will return true if ok > button is clike,return false if cancal button is cliked. ok, now the > problem is that if command script call messagebox.show the Hecl Interp must > to be pasued util the messagebox.show return a bool variable. so i think > that Interp must hava to function pasue() and wakeup() .call the pasue() > Interp will be pasued call the wakeup() the Interp will wake up. i think > Interp need not extends Thread , i think script should not run all the time, > beacuse it is slowly. just run the script if MIDlet need. and anytime can > pasue the Interp if MIDlet call the function pasue() . i hope you can updata > the sourcecode and write less code ,and make it as simplely as possible . > thanks you! Ok - I'm not entirely clear on what it is you want to do. Do you want the Hecl interpreter to keep running while your message box is on the screen? Or do you want the 'ok' button to call some Hecl code? -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: j2mecrazy <j2m...@12...> - 2009-08-12 13:10:08
|
hello , i am a j2me developer, i think your Hecl language is a good j2me script language,i am very intreasting in it. i hava dowanload the Hecl sourcecode, and try to read it .i found that your Hecl Interp is not very simple, it has some trashy feature,the Interp is extends Thread, to run a script need to start a Thread,i think this is not a good idea! because it may be bring some synchronization problem ,and it is not very fast if you use two Thead in a MIDlet. on the other hand i think Hecl not hava some feature, for example i write a Lib for my MIDlet, it has a command messagebox.show(String message) if call it ,it will return true if ok button is clike,return false if cancal button is cliked. ok, now the problem is that if command script call messagebox.show the Hecl Interp must to be pasued util the messagebox.show return a bool variable. so i think that Interp must hava to function pasue() and wakeup() .call the pasue() Interp will be pasued call the wakeup() the Interp will wake up. i think Interp need not extends Thread , i think script should not run all the time, beacuse it is slowly. just run the script if MIDlet need. and anytime can pasue the Interp if MIDlet call the function pasue() . i hope you can updata the sourcecode and write less code ,and make it as simplely as possible . thanks you! 没有广告的终身免费邮箱,www.yeah.net |
From: David W. <dav...@gm...> - 2009-08-12 10:32:00
|
[ Lots of interesting stuff here - I'd encourage everyone to read this mail fully ] On Wed, Aug 12, 2009 at 2:52 AM, Zakaria<z4...@gm...> wrote: > On Wed, Aug 12, 2009 at 5:22 AM, David Welton<da...@de...> wrote: >>> 1. You haven't build the packageJarHack > >> In what sense? It gets built as part of everything else. > > The one in jars/JarHack.jar is the old version without the icon fix patch Maybe I just haven't committed it in a while? Let me update it and see if it's still old. >>> 2. How about my key-remap.patch? >>> I'll send newer one with mapping for Nokia XpressMusic and >>> Samsung SGH i550 >> Let's talk about this idea some more. Would your idea be to remap all >> keys for all phones into something standard? >> Maybe you could write a little Hecl script for everyone to try, to see >> what sorts of names various keys have on our phones... >> Ideally, we'd be able to do this without a hash table lookup for each >> value, based on the keycode, but I realize that there is a lot that's >> not ideal about x-platform j2me... > Are the keycode standardized? No: http://www.j2meforums.com/wiki/index.php/Canvas_Keycodes > I mean is the left key's keycode on one phone to another is the same? > > I'm new to this J2ME phone thing, but I got some experience coding in > J2ME for Siemens Industrial GSM modem. > > >From the point of hecl programmer comparing by standarized keyname > is easier to understand rather than comparing with some number that > represent keycode. Agreed. What I meant is that instead of looking up the name and mapping that, it would make sense to get a numeric keycode and return a name based on that? It's a complex/ugly side of Java ME though: http://www.javaeye.com/topic/179073 I think Hecl should definitely include code to make this stuff easy for people - I don't want to just push the phone mapping stuff down into people's individual Hecl scripts. I think it will take some effort, and more research, though. Wolfgang is more of an expert than I am in terms of running Hecl on a wide variety of phones, hopefully he will have a moment to comment. > Okay everyone please test your phone with the attached script. > That script also exists as an example on my Hecl-IDE.hcl attached on > previous mail. > >>> 3. How about replacing midp20\script.hcl with my Hecl-IDE.hcl? > >> It's been 'script.hcl' for a while - any particular reason to change the name? > > I mean the content, not the name. I attach it in the previous mail. Oh, oops, sorry, I didn't see that! Nice work! I like your code, and think we can use that as the code that Hecl ships with. Like the one I did for Android, I like the fact that you can view the source code and edit it. I also like the creativity. I have gone ahead and committed it, but do think it needs some modification or at least consideration of various elements. Hecl, not being widely used, doesn't have a defined style that people need to use, so that means we're also free to define things as we see fit. That said, your code is a bit different than most Hecl code I've seen (or written) so far. That's not necessarily a bad thing, but since this is going to be *the* example script, it's important that we talk about it a little bit. In particular: * The : in front of global variables. Distinguishing them like that is not a bad idea, but I'm undecided whether I'd use it myself. * proc's with :LeadingColons - I don't really see the benefit. You know from the structure of Hecl what's a proc: it's always the first word in a group. With the :globalvars, it also leads to a few too many :'s around for my tastes:-) * Hecl indentation is definitely 4 :-) There are also some things that, while I think they are good Hecl, or sensible, need some thinking about just because script.hcl has to be held to a high standard, and is something many people will likely look at. * 'Short' names. that's very handy if you're editing the script on the phone, but less so if someone is looking to grab a bit of example code and use it in their own script. * Redefining proc makes things confusing. I think it might make more sense to create your own command along the lines of AliasProc, and add a comment that it adds a bunch of aliases. Lastly, your code suggests a few things that might be interesting to add to Hecl itself: * Command aliases. Having short commands to type is nice, but the mechanism you end up using is a bit circuitous, and would be a lot easier if you could jsut write: alias /alert lcdui.alert * Anonymous commands, which you use ':' for (are you a Forth fan?:-). That requires some more experimentation, but it's an interesting idea... > OK, Alert.FOREVER works, last time I try to change to 120000 but still > not works. Maybe a bug in Alert timeout on my phone? Ok, I will test that out a bit more and then commit it. > Sure, send it out to me. But I think it's better to do some test release > so more people could test it on various phone. We can try a few; hopefully not too many people here in Europe are on vacation and can give things a test. Also, thanks! The more people get involved like this, the more it pushes me to do more to improve Hecl. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: Zakaria <z4...@gm...> - 2009-08-12 00:52:45
|
On Wed, Aug 12, 2009 at 5:22 AM, David Welton<da...@de...> wrote: >> 1. You haven't build the packageJarHack > In what sense? It gets built as part of everything else. The one in jars/JarHack.jar is the old version without the icon fix patch >> 2. How about my key-remap.patch? >> I'll send newer one with mapping for Nokia XpressMusic and >> Samsung SGH i550 > Let's talk about this idea some more. Would your idea be to remap all > keys for all phones into something standard? > Maybe you could write a little Hecl script for everyone to try, to see > what sorts of names various keys have on our phones... > Ideally, we'd be able to do this without a hash table lookup for each > value, based on the keycode, but I realize that there is a lot that's > not ideal about x-platform j2me... Are the keycode standardized? I mean is the left key's keycode on one phone to another is the same? I'm new to this J2ME phone thing, but I got some experience coding in J2ME for Siemens Industrial GSM modem. >From the point of hecl programmer comparing by standarized keyname is easier to understand rather than comparing with some number that represent keycode. Compare the following script fragment: set key [$event cget -keyname] if {eq $key UP} { set Y [+ $Y 10] } elseif {eq $key DOWN} { set Y [- $Y 10] } elseif {eq $key LEFT} { set X [- $X 10] } elseif {eq $key RIGHT} { set X [+ $X 10] } with: set key [$event cget -keycode] if {= $key -1} { # UP set Y [+ $Y 10] } elseif {= $key -2} { # DOWN set Y [- $Y 10] } elseif {= $key -3} { # LEFT set X [- $X 10] } elseif {= $key -4} { # RIGHT set X [+ $X 10] } Which one you think could be easier to read and understand by Hecl newbie? Unless you plan to add constant into Hecl: set key [$event cget -keycode] if {= $key @KEY_UP@} { set Y [+ $Y 10] } elseif {= $key @KEY_DOWN@} { set Y [- $Y 10] } elseif {= $key @KEY_LEFT@} { set X [- $X 10] } elseif {= $key @KEY_RIGHT@} { set X [+ $X 10] } Okay everyone please test your phone with the attached script. That script also exists as an example on my Hecl-IDE.hcl attached on previous mail. >> 3. How about replacing midp20\script.hcl with my Hecl-IDE.hcl? > It's been 'script.hcl' for a while - any particular reason to change the name? I mean the content, not the name. I attach it in the previous mail. >> 4. On my dinky hand phone I keep getting "Nothing to display" after >> "Loading Hecl..." alert and then after several seconds, Hecl finally >> running the script. I try to increase a.setTimeout in >> midp20\Hecl.java but no luck. > How many seconds does it take? The limit is currently set at 10 > seconds. I tried an experiment: updating the alert text as things > proceed in the init phase, to give people an idea that something's > happening, but it looks really ugly on my phone. Are you sure you > recompiled the right thing? Try setting it to Alert.FOREVER instead > of a value, and see if that improves things. OK, Alert.FOREVER works, last time I try to change to 120000 but still not works. Maybe a bug in Alert timeout on my phone? >> Maybe you should do an RC release first. > If you're willing to help test it out, I would love to get some QA > before releasing the code:-) Normally I just go ahead and dump stuff, > but if you want to help pick out problems, that is something that > would be extremely useful. Sure, send it out to me. But I think it's better to do some test release so more people could test it on various phone. > Thanks! > -- > David N. Welton -- Zakaria z4...@gm... Yahoo!: z4k4ri4 http://tukangprogram.com http://pemula.linux.or.id |
From: David W. <dav...@gm...> - 2009-08-11 22:38:04
|
I managed to get it running. The most difficult part is actually keeping the fragile emulator up and running on Linux. Getting blackberry working wasn't that tough... a few modifications to midp20/script.hcl (committed) and some build scripts (still not in svn), and things are done! Of course, not everything works quite right, so I'll be investigating that in the coming days. More importantly, I'll also be attempting to prioritize (together with my sponsor/client, of course!) priorities for implementing the BB API's. Of course, suggestions and comments are welcome if you have some ideas about what to work on to really bring Hecl to Blackberry. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: David W. <da...@de...> - 2009-08-11 22:22:45
|
> 1. You haven't build the packageJarHack In what sense? It gets built as part of everything else. > 2. How about my key-remap.patch? > I'll send newer one with mapping for Nokia XpressMusic and > Samsung SGH i550 Let's talk about this idea some more. Would your idea be to remap all keys for all phones into something standard? Maybe you could write a little Hecl script for everyone to try, to see what sorts of names various keys have on our phones... Ideally, we'd be able to do this without a hash table lookup for each value, based on the keycode, but I realize that there is a lot that's not ideal about x-platform j2me... > 3. How about replacing midp20\script.hcl with my Hecl-IDE.hcl? It's been 'script.hcl' for a while - any particular reason to change the name? > 4. On my dinky hand phone I keep getting "Nothing to display" after > "Loading Hecl..." alert and then after several seconds, Hecl finally > running the script. I try to increase a.setTimeout in > midp20\Hecl.java but no luck. How many seconds does it take? The limit is currently set at 10 seconds. I tried an experiment: updating the alert text as things proceed in the init phase, to give people an idea that something's happening, but it looks really ugly on my phone. Are you sure you recompiled the right thing? Try setting it to Alert.FOREVER instead of a value, and see if that improves things. > Maybe you should do an RC release first. If you're willing to help test it out, I would love to get some QA before releasing the code:-) Normally I just go ahead and dump stuff, but if you want to help pick out problems, that is something that would be extremely useful. Thanks! -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: Zakaria <z4...@gm...> - 2009-08-11 21:49:02
|
On Mon, Aug 10, 2009 at 2:03 PM, David Welton<dav...@gm...> wrote: > I also think it is probably time to switch to a numbered release system... Just some small things: 1. You haven't build the packageJarHack 2. How about my key-remap.patch? I'll send newer one with mapping for Nokia XpressMusic and Samsung SGH i550 3. How about replacing midp20\script.hcl with my Hecl-IDE.hcl? 4. On my dinky hand phone I keep getting "Nothing to display" after "Loading Hecl..." alert and then after several seconds, Hecl finally running the script. I try to increase a.setTimeout in midp20\Hecl.java but no luck. Maybe you should do an RC release first. > -- > David N. Welton -- Zakaria z4...@gm... Yahoo!: z4k4ri4 http://tukangprogram.com http://pemula.linux.or.id |
From: David W. <dav...@gm...> - 2009-08-11 20:44:08
|
On Tue, Aug 11, 2009 at 9:16 PM, Mario Zorz<mar...@ya...> wrote: > Great!! thanks a lot David, i will try that > > Have that helped your debugging? Very much so! I nearly have things running! -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: Mario Z. <mar...@ya...> - 2009-08-11 19:42:38
|
No actually it passes the XML reading al ok. Even I tried parsing out the hecl script file and it seems to pass all ok as well - not sure about actually running Hecl as I'm still stuck trying to show *something* on the screen. I have succeeded in doing so with just a simple canvas hello world app, of course. regards Mario ________________________________ From: David Welton <dav...@gm...> To: Hecl Devel <hec...@li...> Sent: Tuesday, August 11, 2009 2:58:41 AM Subject: Re: [Hecl-devel] Phew... BB Emulator running > Also I got Prosciutto to run, but it shows nothing (all screen blank), yet I > know it's running because of some tweaks I speciifcally made to see if it is > in control - setCurrent to a Textbox class works at some point. I don't know > what's happening with my Canvas thing anyway. Any idea where it's hanging? I suspect that you load some resources like a .hcl file or .xml file or something... correct? Does it seem to make it to that point ok? -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Hecl-devel mailing list Hec...@li... https://lists.sourceforge.net/lists/listinfo/hecl-devel |
From: Mario Z. <mar...@ya...> - 2009-08-11 19:23:24
|
Great!! thanks a lot David, i will try that Have that helped your debugging? ________________________________ From: David Welton <dav...@gm...> To: Hecl Devel <hec...@li...> Sent: Tuesday, August 11, 2009 10:29:44 AM Subject: Re: [Hecl-devel] Phew... BB Emulator running > I believe what you say! I'm still struggling with it on Windows to get > System.errs output for instance :( In the emulator script (like 9500.bat), you can do: /app-param=JvmDebugFile=out.txt As one of the arguments, and System.out will be sent to that file... Maybe err is something similar? -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Hecl-devel mailing list Hec...@li... https://lists.sourceforge.net/lists/listinfo/hecl-devel |
From: David W. <dav...@gm...> - 2009-08-11 13:29:52
|
> I believe what you say! I'm still struggling with it on Windows to get > System.errs output for instance :( In the emulator script (like 9500.bat), you can do: /app-param=JvmDebugFile=out.txt As one of the arguments, and System.out will be sent to that file... Maybe err is something similar? -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |
From: David W. <dav...@gm...> - 2009-08-11 05:58:52
|
> Also I got Prosciutto to run, but it shows nothing (all screen blank), yet I > know it's running because of some tweaks I speciifcally made to see if it is > in control - setCurrent to a Textbox class works at some point. I don't know > what's happening with my Canvas thing anyway. Any idea where it's hanging? I suspect that you load some resources like a .hcl file or .xml file or something... correct? Does it seem to make it to that point ok? -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ Sent from Padua, Veneto, Italy |