Re: InvibleShield at ZAGG : swindling ?!?
Cédric DUFOUIL <[EMAIL PROTECTED]> writes: > > Hi community,I ordered an InvibleShield protection at Zagg.com for my freerunner the 18th of july and have been charged on my credit card but have no news about my order (despite the fact that I sent them emails !!)I would like to know if any of you had troubles ordering on this web site. Did you receive your order ?Thanks for your testimony(PS : Sorry if my email is not well formed, I'm not an English speaker) > I ordered 3 of the screen protectors a few days after the OpenMoko web shop opened. I chose the free shipping option. I received the package in about 2 weeks (USA). I had it shipped to a business address. By the way, I think this product is really great and worth the money. It's clearly saved my screen multiple times already (I was moving over the weekend with it in my pocket). It's much more durable than other screen protectors I've used. Just my $0.02. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Warranty after fix for GTA02 GPS rework for SD card interferenceissue
Al Johnson <[EMAIL PROTECTED]> writes: > We only need to replace 1 of the 2 3D accels with a 3D gyro. I've not looked > at the size or cost of solid state gyros so I don't know how practical that > might be. > That's not a bad idea... I haven't looked into what accelerometers we have in the FR, but there are plenty of MEMS gyros available; maybe one will have the same or similar pin configuration. I know the gyros and accelerometers made by Analog Devices are very close to pin compatible. Last time I checked (about a year ago), there weren't any 3D MEMS gyros on the market. There was one company offering what was basically 2 2D gyros glued to each other. I think there's some kind of manufacturing hurdle that has to be overcome to make them 3D, so they may not be available in a small size or integrated unit. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Russell Sears <[EMAIL PROTECTED]> writes:
>
> I fell out of this discussion for a while, but I'd much rather see a
> very simple C API that delivers events from DBUS with bindings for
> python / your favorite language. The event system and programming model
> (rule based, prolog, python, ...) should be completely separate modules.
> That way, you don't need to design your application around being able
> to receive external events.
>
> Also, if we couple the event system to the programming language, then
> all other languages become second class citizens. That would suck.
>
> I'd like to clarify my original post. (Also, I still haven't looked at
> D-BUS, it might already do most/all of this stuff.)
>
> These two lines are meant to be function invocations, perhaps in C or in
> python:
>
> register_event_handler("/phone/incoming_call = true",
> mute_music_callback)
>
> register_event_handler("/clock/time = 600",
> play_alarm_callback,
> "loud_buzzer.ogg")
>
> register_event_handler() should be a C function that takes three arguments:
>
> 1: A char* containing a query written in a small domain specific
> language. I don't think we need support for more than:
>
> a) =, <, >, ...
> b) Conjunction + disjunction; && and ||, which means "all of" or "one
> of" these rules match
>
> The following two would be nice, but might make things harder to implement:
>
> a) Parenthesis for grouping
> b) Negation
>
> xpath is a well-known language, and is close, though I don't know how
> well existing implementations deal with events (ie: third parties making
> changes to the underlying xml document). Also, I think xpath is
> probably too complicated.
>
> 2: A function pointer of type void (fcn*)(void *)
>
> This gets invoked when the evaluation of the query changes from false to
> true.
>
> 3) A void *
>
> The application program controls what goes in the void*.
>
> Applications should be able to build all sorts of things with these
> primitives, including new domain specific languages.
>
> It would be good to make sure that it's easy to have prolog or some
> other rule based system autogenerate and interface to the small domain
> specific language. I think the way it would work is prolog would use
> some event handlers to maintain a table of facts that the DSL would then
> use as its base database.
>
> Also, datalog would be a much better choice than prolog. The outcome of
> prolog programs depends on the order in which rules are defined. This
> isn't true for datalog, which has cleaner semantics. The two languages
> have nearly identical syntax.
>
> -Rusty
>
I think I may have been unclear... I was suggesting Prolog for the "small
domain-specific language" you're talking about. Nowadays, pretty much no one
writes entire applications in Prolog, they just use it within another language
to implement a rules engine. I know nothing of Datalog, but I'll take your word
for it that it's better -- if it's similar to Prolog, I'm sure it will get the
job done. A logic-based language has all the primitives you mentioned (and
indeed all of first-order logic). Learning Prolog well enough to use it for
this purpose would probably take all of half an hour and can be accomplished by
reading the wikipedia page (with examples). It seems to be a ready-made
solution to exactly this problem with a minimal startup time. As it is only the
"domain-specific language", the application it resides in (some kind of
dbus-connected event server?) can be in any language that we can get a prolog
interpreter for, which basically means any of the common ones like C++ or Java
(and probably python). I think I may have unintentionally confused a few people
by suggesting Prolog as the language when it itself can be compiled to a binary.
If you really wanted to, you could use Prolog for the whole app, but I just
suggest it for the rule interpreter itself.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
matt joyce <[EMAIL PROTECTED]> writes: > Ryan, what approach have your efforts taken already? > Any interesting insights to the problem? > > Matt > My efforts as far as applying my inference engine to the OpenMoko platform basically consist of a few ideas rattling around in my head -- nothing concrete. I'm not a professional at this stuff, just an enthusiastic amateur trying to follow in the footsteps of some of the very interesting early AI research projects (most inference-based approaches to AI died out in the 80's, but a few are still around). To that end, most of my work has been focused on things not directly useful to a phone platform. I think it's important that we use an existing general-purpose platform such as Prolog (at least, it's about as general purpose as logic programming gets...). This saves us from reinventing the wheel and also prevents us from thinking ourselves into a corner -- a general purpose system will likely be much more extensible and flexible for powerusers (and with this device, who isn't?) than something we dream up. Taking an inference-based approach to setting up the rules in the phone could allow us to create rules that are more abstract than most of the examples I've seen on this list. Instead of telling it "don't use the ringer when I'm at the office", it could be "don't use the ringer when I'm doing work". "Work" would be defined by other rules, such as your proximity to the office, whether or not you've scheduled an appointment in the calendar with contacts from work (think lunch meeting), and if you have a deadline that isn't marked as complete and it's only an hour away (you're probably workign furiously to meet it). That's just an example I created just now, and not particularly good -- good examples are hard to think of, but that's largely because the possibilities are endless. As one other person on the mailing list noted, the possible configurations of the rules engine that are nonsensical outnumber the meaningful ones by millions to one :) That babbling probably wasn't very helpful to anyone, but maybe it will at least build enthusiasm. I think the gist of it was mostly this: make it more flexible than it needs to be, and also make the rules capable of building on top of each other to create more complex conditions. Just my $0.02 :) Ryan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Steven Kurylo <[EMAIL PROTECTED]> writes: > > > The problem with this is that one needs to think like a programmer to > > describe your "ideal phone" as a set of rules like these. Not only does > > one have to think analytically and dissect their concept into orthogonal, > > machine-checkable rules, but from your examples it's also clear that for > > such a wide range of possibilities a whole *language* with *expressions* > > (at least boolean) is necessary. > > I see it as something like sieve. Its a pretty full language for > writing rules. I, as a programmer, I do almost anything I want. For > the non-programmers there are various GUIs which allow you to do all > the simple tasks with a couple clicks. In fact filter email is fairly > similar: if these three things are true, do X. Then I have a stack of > rules and it goes through them one at time until one is true. > > xpath might work. There are a few options, though I would try to stay > away from writing our own if it can be helps. A plan old python class > might be enough with function for each possible condition. > I think what we're looking for here is Prolog (or something very similar). http://en.wikipedia.org/wiki/Prolog. I'd be very interested in contributing to (and using!) a rule-based system such as this. In addition to providing an inference-based rules engine written in first order predicate logic, it has the unique ability of adding rules with side effects (basically executing native code) when certain things happen... I think it would work nicely (it basically is for this purpose). I already had plans to create a rule-based system for the moko myself (an adaptation of a prolog-like inference system that I already have under construction). Due to the memory and processing constraints on the moko and the desire to reuse code whenever possible (which I agree with wholeheartedly), I think going with Prolog is probably a better choice than trying to finish my hacked-together and unproven inference engine. Now if only my Freerunner would arrive... dunno why it's been delayed by a week before shipping. Ryan Meador ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
