[urbit] awk

[Curtis Yarvin]

Anyone know awk/perl/whatever like the back of their hand? I'm
touching up the new syntax and need to replace

__(whatever)

where "whatever" may include arbitrary matching parens, with

_whatever

I'd just write it in C but that seems lame; I'd write it in Hoon but
our unix integration is poor...

[Andrew Harkness]

A quick test shows that:

sed -i 's/\_\_(\(.*\))/_\1/' <file>

gets the job done. Might want to try on a single file first - I would
hardly call myself an expert....

-Andrew

Post by Curtis Yarvin
Anyone know awk/perl/whatever like the back of their hand? I'm
touching up the new syntax and need to replace
__(whatever)
where "whatever" may include arbitrary matching parens, with
_whatever
I'd just write it in C but that seems lame; I'd write it in Hoon but
our unix integration is poor...

[Andrew Harkness]

Wait, I spoke a little soon... that one only does one replace per line. My
sed is apparently just as bad as I initially suspected...

-Andrew

Post by Curtis Yarvin
Anyone know awk/perl/whatever like the back of their hand? I'm
touching up the new syntax and need to replace
__(whatever)
where "whatever" may include arbitrary matching parens, with
_whatever
I'd just write it in C but that seems lame; I'd write it in Hoon but
our unix integration is poor...

[Raymond Pasco]

No* regular expression will ever be able to balance brackets. Regular
grammars are equivalent to those that you can validate with a finite state
machine, and for any finite state machine with n states you give me to
balance brackets, I can pass it a string starting with n+1 opening brackets.

*: Obviously, Perl can. Most "regular expression" engines handle something
much more complicated than mere regular expressions.

(re: original query - you can, of course, write things to clay from dojo
with the *output/path +whatever syntax, though for some ungodly reason
whatever ford mangling happens there sees fit to put html boilerplate in
whenever I've used this, but it's just two lines at the very top and bottom
you can kill fast - that's what I'd do, because I'd never do anything but
just write the counter machine)

Yours,
r

[Anton Dyudin]

Please do file the html boilerplate bug, *foo/md 'bar' should work!

The problem here is the filter is being applied to /all hoon files in
clay/, which in shell would be simply `perl 
 urb/**.hoon`, but dojo
requires explicit side effects on generators. Though I suppose having a
lib/kiln endpoint that took a ++toro, and recursive generator similar to
+tree that generated one accordingly, would work here.

Post by Raymond Pasco
No* regular expression will ever be able to balance brackets. Regular
grammars are equivalent to those that you can validate with a finite state
machine, and for any finite state machine with n states you give me to
balance brackets, I can pass it a string starting with n+1 opening brackets.
*: Obviously, Perl can. Most "regular expression" engines handle something
much more complicated than mere regular expressions.
(re: original query - you can, of course, write things to clay from dojo
with the *output/path +whatever syntax, though for some ungodly reason
whatever ford mangling happens there sees fit to put html boilerplate in
whenever I've used this, but it's just two lines at the very top and bottom
you can kill fast - that's what I'd do, because I'd never do anything but
just write the counter machine)
Yours,
r
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:;>.
For more options, visit https://groups.google.com/d/optout.

[Anton Dyudin]

The simplest way to do the editing within urbit probably involves a round
trip through shar as a multifile-editing enabler. The simplest with sed
would be transmuting ([^()]*) to e.g. X{X X}X repeatedly until no parens
were left in the line, and then back.

Post by Anton Dyudin
Please do file the html boilerplate bug, *foo/md 'bar' should work!
The problem here is the filter is being applied to /all hoon files in
clay/, which in shell would be simply `perl 
 urb/**.hoon`, but dojo
requires explicit side effects on generators. Though I suppose having a
lib/kiln endpoint that took a ++toro, and recursive generator similar to
+tree that generated one accordingly, would work here.

Post by Raymond Pasco
No* regular expression will ever be able to balance brackets. Regular
grammars are equivalent to those that you can validate with a finite state
machine, and for any finite state machine with n states you give me to
balance brackets, I can pass it a string starting with n+1 opening brackets.
*: Obviously, Perl can. Most "regular expression" engines handle something
much more complicated than mere regular expressions.
(re: original query - you can, of course, write things to clay from dojo
with the *output/path +whatever syntax, though for some ungodly reason
whatever ford mangling happens there sees fit to put html boilerplate in
whenever I've used this, but it's just two lines at the very top and bottom
you can kill fast - that's what I'd do, because I'd never do anything but
just write the counter machine)
Yours,
r
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
Cabmold delenda est

[Curtis Yarvin]

Sorry, awk jockeys, I wrote it in C :-|

Post by Anton Dyudin
The simplest way to do the editing within urbit probably involves a round
trip through shar as a multifile-editing enabler. The simplest with sed
would be transmuting ([^()]*) to e.g. X{X X}X repeatedly until no parens
were left in the line, and then back.

Post by Anton Dyudin
Please do file the html boilerplate bug, *foo/md 'bar' should work!
The problem here is the filter is being applied to /all hoon files in
clay/, which in shell would be simply `perl … urb/**.hoon`, but dojo
requires explicit side effects on generators. Though I suppose having a
lib/kiln endpoint that took a ++toro, and recursive generator similar to
+tree that generated one accordingly, would work here.

Post by Raymond Pasco
No* regular expression will ever be able to balance brackets. Regular
grammars are equivalent to those that you can validate with a finite state
machine, and for any finite state machine with n states you give me to
balance brackets, I can pass it a string starting with n+1 opening brackets.
*: Obviously, Perl can. Most "regular expression" engines handle something
much more complicated than mere regular expressions.
(re: original query - you can, of course, write things to clay from dojo
with the *output/path +whatever syntax, though for some ungodly reason
whatever ford mangling happens there sees fit to put html boilerplate in
whenever I've used this, but it's just two lines at the very top and bottom
you can kill fast - that's what I'd do, because I'd never do anything but
just write the counter machine)
Yours,
r
--
You received this message because you are subscribed to the Google Groups
"urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
Cabmold delenda est

--
Cabmold delenda est
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Raymond Pasco]

aka, Unix's only decent text processing scripting language.

Yours,
r

[c***@gmail.com]

What's that? Our god-emperor can't even defeat a lowly pumping lemma? So much for martian engineering...

Trolling aside, are we finally going to see all the syntax changes that have been in the works?