This is very usefull in order to can select what is sent
to the plumber.
---
config.def.h | 1 +
st.c | 32 +---
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/config.def.h b/config.def.h
index 47018a3..58b470e 100644
--- a/config.def.h
+++ b/c
This sequence print the current line. It is different to the
'printer on' sequence, where all the characters that arrive to the
terminal are printer. Here only the ascii characters are printed.
---
st.c | 41 -
1 file changed, 32 insertions(+), 9 deletions(-
This sequence is very useful because allows comunicate the content
of the terminal to another program.
---
st.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/st.c b/st.c
index e60643c..1711842 100644
--- a/st.c
+++ b/st.c
@@ -358,6 +358,7 @@ static void strreset(void);
static i
These new combinations generate the same behaviour (basically) of
vt102. It is a good way of communicating st with other programs.
[0] http://www.vt100.net/docs/vt102-ug/chapter2.html
---
config.def.h | 2 ++
st.c | 12
2 files changed, 14 insertions(+)
diff --git a/config.
These capabilities inform to programs how print in local printer
of the terminal.
---
st.info | 3 +++
1 file changed, 3 insertions(+)
diff --git a/st.info b/st.info
index 7526141..4e60a89 100644
--- a/st.info
+++ b/st.info
@@ -152,6 +152,9 @@ st| simpleterm,
ncv#3,
op=\E[39;49m,
This sequence control when the printer is enabled or disabled. This
sequence control the behaviour of the -o option.
---
st.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/st.c b/st.c
index cad61bf..314bf3f 100644
--- a/st.c
+++ b/st.c
@@ -134,6 +134,7 @@
On 04/03/2014, Bobby Powers wrote:
> Strake wrote:
>> * Member selection is in some cases cumbersome, in which it would not
>> be in C, which is related to ¬(variant types)
>
> Can you explain more what you mean?
I can't quite remember the particulars. My case was a λ-calculus
interpreter, which
Hi,
2014-03-05 16:58 GMT+01:00 FRIGN :
>> C programs can also be run as scripts, but it doesn't make C a
>> scripting language.
>
> Where did you pick that up?
Several options are available for using C as a scripting language:
http://stackoverflow.com/a/1513961/131264
> I agree on that point. L
On Wed, 5 Mar 2014 18:20:43 +0100
Alexander Rødseth wrote:
> If you don't think the definition of a compiled language is that it
> can be compiled down to native code, I would love to hear your
> definition.
Well, then any language would be a compiled language.
The problem here is, that the lang
Hi,
2014-03-05 15:41 GMT+01:00 FRIGN :
> Well, you could also compile shell-scripts if you had the time to write
> the proper interfaces. Does this make it a compiled language? Hell no!
Yes, if shell-scripts are _compiled_ to native code, then it would
make them _compiled_.
> It still is a scr
On Wed, 5 Mar 2014 17:26:46 +0100
Alexander Rødseth wrote:
> Nuitka compiles Python to C++. I never made any claims about speed and
> think the two should not be conflated.
> Python can now also be compiled, and should be counted as a compiled language.
Well, you could also compile shell-scripts
Hi,
2014-03-05 15:05 GMT+01:00 FRIGN :
> Benchmarks or it didn't happen.
Nuitka compiles Python to C++. I never made any claims about speed and
think the two should not be conflated.
Python can now also be compiled, and should be counted as a compiled language.
> Or just leave it to the develop
On Wed, 5 Mar 2014 16:50:58 +0100
Alexander Rødseth wrote:
> After Nuitka arrived (http://nuitka.net/), Python is also a "proper
> compiled language" (if it wasn't already, because of Shedskin
> http://code.google.com/p/shedskin/).
Benchmarks or it didn't happen. Python-compilers aren't a new th
Hi,
2014-03-03 23:25 GMT+01:00 koneu :
> Isn't Python that white space sensitive crap people like to use instead
> of proper compiled languages?
After Nuitka arrived (http://nuitka.net/), Python is also a "proper
compiled language" (if it wasn't already, because of Shedskin
http://code.google.co
Hey,
As a new Python programmer, there are only a few things that have so
far bothered me:
* Python 2-3 transition (I ended up learning 2 "by accident", but
easily learned 3 as they are quite similar)
* Packaging/Module system (Maybe just because I haven't had enough
experience with it...)
* Pyth
Easily readable, writable, maintainable.
You also have the magical "import". You just import an asian and he
writes the code for you... :P
(no racism, just joking)
On Wed, Mar 5, 2014 at 4:28 PM, koneu wrote:
> On 03/05/2014 03:03 PM, pancake wrote:
>>
>> That thread would be smarter.
>
> Nope, j
On 03/05/2014 03:03 PM, pancake wrote:
That thread would be smarter.
Nope, just much less entertaining to read.
That thread would be smarter.
The name.
On Wed, 05 Mar 2014 14:49:07 +0100
Troels Henriksen wrote:
> A solution to this is to implement the GC (and other runtime parts) as a
> dynamic library. This code would also be shared in memory by all
> running Go processes.
Well, I tried that and it worked. The Hello-World-binary is around 19K
FRIGN writes:
> Yes, that's a point. Go implements GC and other stuff in the binary,
> which blows its size up a lot.
> However, if we take the Hello-World-program as the lowest common
> denominator, we could calculate, that if we ported all basic tools in
> sbase (currently 70) to the Go languag
On Wed, 5 Mar 2014 00:16:13 -0800
Anthony Martin wrote:
> People are working on this:
Well, then let's see what time will bring us ;).
Cheers
FRIGN
--
FRIGN
On Wed, 5 Mar 2014 16:27:24 +0800
Chris Down wrote:
> Storage space is really cheap. If there is some reason that it is
> desirable for the binaries to be bigger as a tradeoff, I am all in
> favour of it (of course, if the binary size can be reduced without much
> complication, I'm also in favour
I've been using a solarized patch for quite a while, which looks a bit
different to yours. There's a collection which can be found here
https://gist.github.com/drm00/5712443
I use config-h-solarized_light.patch and st-c-no_bold_colors.patch
* Michael Hauser [04.03.2014 23:26]:
> Hi,
>
> I jus
On Tue, Mar 4, 2014 at 10:34 PM, Szabolcs Nagy wrote:
> * Silvan Jegen [2014-03-04 21:30:47 +0100]:
>> On Tue, Mar 04, 2014 at 08:56:18PM +0100, Szabolcs Nagy wrote:
>> > dont expect fast opengl access from go) and you cannot really
>> > use it for quick scripting tasks
>>
>> Why should Go not be
FRIGN writes:
> Well, what I noticed is the huge size of the compiled binaries.
> 2.2M for a "Hello World"-program is an unreasonable demand. It's
> possible to strip the size to around 1.2M by passing
> -ldflags '-s -w'
> to "go build".
> This is quite inhibiting, but I'm glad to see this mo
FRIGN once said:
> Well, what I noticed is the huge size of the compiled binaries.
> 2.2M for a "Hello World"-program is an unreasonable demand. It's
> possible to strip the size to around 1.2M by passing
> -ldflags '-s -w'
> to "go build".
> This is quite inhibiting, but I'm glad to see thi
27 matches
Mail list logo
