|
Dij is far too busy hacking (and slashing) the mice ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I gave up on trying to get our cat to do anything, when I was 12 yrs. old.
Of course, I did not have a computer, nor did I know how to write programs at the time.
ED
|
|
|
|
|
I dreamed my cat left me a present ... but it was only a dream. Whew.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
You need a mouse to do this.
|
|
|
|
|
Most apropos reply so far !
Software Zen: delete this;
|
|
|
|
|
You only have 9 chances to call the API.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I guess your cat became a laptop... Like someone said, CatScript.
|
|
|
|
|
My kids have been sql procs that I needed to call in the right order. I totally get that.
|
|
|
|
|
Isn't this exactly what Scratch was built for?
Or maybe I'm thinking of Claw.
Either way, will probably end horribly.
|
|
|
|
|
You are aware that the algorithm for getting a cat to move of its own volition is classified as NP-hard[^]?
Software Zen: delete this;
|
|
|
|
|
I even have a partial implementation:
string PullTail()
{
return "Meeeewwwwww".
}
Nick Polyak
|
|
|
|
|
Let me know when you can disable the mouse cord attack mode and enable keyboard avoidance.
Money makes the world go round ... but documentation moves the money.
|
|
|
|
|
Maybe a short one, Chris. Then back on your head!
Will Rogers never met me.
|
|
|
|
|
I decided to start shoring up the regular expression syntax I use, and settling on something I can more readily document and hopefully mimics what's already out there because I don't want people to have to learn new things just to use my engine.
This is a lot harder than it sounds. For starters most modern engines do backtracking, trading speed and simplicity for expressive power. Mine is simple and fast, but lacks some of the expressive power, which at the end of the day means I can't support certain language constructs - because they require backtracking which my engine doesn't do.
I'm not looking to change that, particularly when my engines are as much as 3 times as fast as Microsoft's .NET regex, and can readily be used for tokenization as a result.
But this leaves me with something of a conundrum.
There are 3 or 4 major regex syntax varieties out there. POSIX, Perl, JS, .NET etc.
I've started with POSIX historically, because it actually means I can use it with certain tools I use - things like FLEX use a POSIXish syntax.
I think I'd like to continue that, but I've noticed, I don't actually need that much POSIX specific nonsense to support almost all FLEX inputs in practice.
I hope I haven't lost or bored you yet. Bear with me.
I'm loathe to add to the syntax nightmare that is regex, so I want to be very careful here.
I'd rather not support multiple "modes" to support different syntax styles like .NET's engine does.
However, I'm thinking of, as much as possible, creating "one syntax to rule them all" as much as I can, such that I can accept constructs allowable in any engine, where possible.
One part of me wants to strangle the other part of me in my sleep for even considering this. /s
The other part of me wonders what the alternative to this mega-syntax is.
90% of this has to do with what is allowed to appear inside [] braces.
Any ideas?
Real programmers use butterflies
|
|
|
|
|
IMHO it is totally acceptable to use a subset of the available commands/syntaxes - just do not introduce something of your own...
Try make that subset compatible with as many flavors as you can (should be easy if you start cutting down from POSIX) so your engine (or a port of it) should run in each environment...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
The problem with that is that your common subset may not be powerful enough to do what you want it to do.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
xkcd: Standards
AKA embrace and extend
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Ha! I had that very comic in mind when I was attacking this.
Real programmers use butterflies
|
|
|
|
|
I'm motivated to make things better, not the same.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Oh but I've already done that.
XBNF is a description language that can describe Chomsky type 2 and Chomsky type 3 languages both using simple compositions of logical constructs like a repeat construct {}, alternation |, concatenation (implicit) etc.
Regex is for the benefit of people that don't want to learn XBNF. It's also for the benefit of leveraging all of the existing regular expressions out there, and this is where it gets important.
If I mimic what's out there it means you can use my tools with the content *you already have* saving you time.
That is an improvement, no?
There's no real reason to "improve" regex. I'd argue that too many already have, leading to the present situation.
I'm not trying to improve that situation. Too many people already have, again leading to the present situation.
I'm simply trying to make the present situation as painless for users of my code as possible.
Real programmers use butterflies
|
|
|
|
|
I am not really good at regex but what about:
Keep your own syntax and offer some sort of "converter" - basically some function that takes a known syntax (POSIX oder .NET or whatever) and returns the "translated" regex which is in your syntax.
This way people choose (perhaps based on knowledge or usecase) which syntax they want to use.
|
|
|
|
|
I've considered that but there are some issues with it, like being able to scan reams of existing regexes (for example in lengthy lexer specifications). It is possible to run each thing through said function, but it's also very difficult to build and test exactly to a syntax versus making a syntax loose enough to accept most constructs from most languages. Doing so easily satisfies the 80/20 rule, so I think that's the way to go.
Real programmers use butterflies
|
|
|
|
|
'as painless ... as possible' is well worth the effort imo.
I wish I could help, but alas, all I can do is encourage. I look forward to seeing what you wind up with.
|
|
|
|
|
I have used Regex provided in various applications, and noticed that some require back slashes in front of operators and others require that they not be used. There seems to be no common ground. The Regex expressions must be different, depending on which app one uses. I would have to have different rules and examples of them for each application.
|
|
|
|
|
I handle escapes by allowing anything to be escaped, but only requiring it where necessary. Most regular expression engines are *supposed to* work that way.
Real programmers use butterflies
|
|
|
|