[chuck-users] New audio programming environment released

[Robin Haberkorn via chuck-users]

Dear ChucK users,

I just released my own new audio programming environment. It draws some
inspiration from ChucK, but really throws a lot of well-established concepts in
the world of real-time audio programming out of the window: first and foremost
the patch graph and the audio/control-rate dualism. All number crunching is in a
Lua, so a dynamic scripting language. It's made possible by LuaJIT, ie. JIT
compilation. Hard to explain really, without a lot of prose. Documentation is
still lacking. My master's thesis about this project will be released soon as
well, but it will be in Russian.
Anyway, I think this little project is at least a fun experiment. Whether it
will really change anything in the world of audio programming is questionable.

Here's the website and repository:
https://rhaberkorn.github.io/applause2
https://github.com/rhaberkorn/applause2

I would be happy to hear some feedback - both in trying to run my code and
regarding my design choices (as far as they are understandable, considering the
lack of introductory material at this point).

Best regards,
Robin
___
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Re: Re: PDF outline not capturing Cyrillic text

[Robin Haberkorn]

On Tue, Feb 06, 2024 at 01:39:51PM +, Deri wrote:
> Hi Robin,
> 
> The current gropdf (in the master branch) does support UTF-16BE for pdf 
> outlines (see attached pdf), but Branden has not released the other parts to 
> make it work! If you can compile and install the current git the applying the 
> attached patch should give you what you want.
> 
> To apply the patch, cd into the git groff directory and "patch -p1 < path-to-
> patch-file", and then run make and install as usual.
> 
> I would be very interested in how you get on, and whether it gives you what 
> you need. Note that I am assuming you are feeding groff a file in UTF-8 and 
> the -k flag. I can see some hyphenation happening, but I don't know if it is 
> correct.
> 
> Cheers 
> 
> Deri

Hello Deri!

This patch works. All the outline titles are correct and .pdfinfo /Title,
/Author etc. also work with Cyrillic.
That's very cool.
But it only works when using UTF-8 as the input encoding (-Kutf-8).
As reported earlier in the correponding Savannah ticket, even hyphenation
works with UTF-8 input and I see no difference to the hyphenation result
compared to KOI-8 input. I have no idea how you did this.
Still, when using UTF-8 input, there are problems (missing letters) with
link texts autogenerated by .pdfhref L.
With KOI-8 input, all the outlines are incomprehensible, ie. they consist of
крокозябры as it would be called in Russian. ;-)
Apparently gropdf does not know, it has to convert from KOI-8 instead of UTF-8.

So I am still going to disable the outlines for the time being and go with
KOI-8.
It's anyway more of a nice to have thing, rather than a necessity.
I need Russian support as I am writing my master's thesis in Russian.
At the end of the day, this will be printed, so I can live without
PDF outlines.

Best regards,
Robin

PS: And to comment on some of the heated discussions on this list:
It's great that you and Branden spend so much time on improving Groff.
I think, you do a great job. Regressions are sometimes unavoidable,
especially when taking over a large code base from somebody else.

[bug #65232] Russian hyphenation is not working

[Robin Haberkorn]

Follow-up Comment #5, bug#65232 (group groff):

[comment #4 комментарий №4:]
> 
> [comment #3 comment #3:]
> > After switching from pdfroff (-Tps) to pdfmom (-Tpdf), hyphenation
suddenly works fine.
> 
> Glad to hear it.
>  
I forgot to mention, I also had to install a new version of the
LiberationSerif fonts as the previous ones I was using, apparently weren't
fully compatible with gropdf. There were for instance some space characters
that were not displayed correctly.

> > Moreover, it will even work with UTF8 input (-Kutf-8), even though that
causes other glitches.
> 
> What glitches are you seeing?
> 
With -Kutf-8, link texts generated by .pdfhref were sometimes missing -
seemingly random - characters.

> The input is coverted from UTF-8 to KOI8-R.  The hyphenation patters are
defined in terms of KOI8-R code points.  The formatter (GNU _troff_) decides
where the hyphens should go and performs the breaks.  The formatter converts
the input characters into internal data structures called "nodes" that do not
use an externally visible encoding.  Then, when generating device-independent
output, each glyph nodes is converted to a device-independent special
character command _if_ the output device supports its code point.  (If it
doesn't, you get a warning like "special character 'u0413' not defined".)
> 
Are you telling me that pdfmom is actually internally converting my text to
KOI8-R after noticing I did -mru?
This is obviously not the case as I tried to print some Cyrillic using .tm and
it comes out as Unicode escapes as would be expected after the sources are ran
through preconv.



___

Reply to this item at:

  

___
Сообщение отправлено по Savannah
https://savannah.gnu.org/

Re: Re: [dev] [st][patch] more work on the XEmbed embedder

[Robin Haberkorn]

 == FocusIn) {
+		XRaiseWindow(xw.dpy, embed);
+		XSetInputFocus(xw.dpy, embed, RevertToParent, CurrentTime);
+		sendxembed(XEMBED_FOCUS_IN, XEMBED_FOCUS_CURRENT, 0, 0);
+		sendxembed(XEMBED_WINDOW_ACTIVATE, 0, 0, 0);
+	}
+
 	if (e->mode == NotifyGrab)
 		return;
 
@@ -1905,9 +1977,17 @@ cmessage(XEvent *e)
 void
 resize(XEvent *e)
 {
+	XWindowChanges wc;
+
 	if (e->xconfigure.width == win.w && e->xconfigure.height == win.h)
 		return;
 
+	if (embed) {
+		wc.width = e->xconfigure.width;
+		wc.height = e->xconfigure.height;
+		XConfigureWindow(xw.dpy, embed, CWWidth | CWHeight, );
+	}
+
 	cresize(e->xconfigure.width, e->xconfigure.height);
 }
 
-- 
2.43.0

>From 4de1ba2a851515da01000f8ed7406d4669bdecc3 Mon Sep 17 00:00:00 2001
From: Robin Haberkorn 
Date: Thu, 1 Feb 2024 17:11:48 +0300
Subject: [PATCH 2/3] Embedder: This respects the embedded window's name/title

Imports gettextprop() from tabbed.c.
---
 x.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/x.c b/x.c
index aaa8139..6b3a8e1 100644
--- a/x.c
+++ b/x.c
@@ -192,6 +192,8 @@ static int match(uint, uint);
 static void createnotify(XEvent *e);
 static void destroynotify(XEvent *e);
 static void sendxembed(long msg, long detail, long d1, long d2);
+static Bool gettextprop(Window w, Atom atom, char *text, unsigned int size);
+static void updatetitle(Window win);
 
 static void run(void);
 static void usage(void);
@@ -524,6 +526,9 @@ propnotify(XEvent *e)
 			(xpev->atom == XA_PRIMARY ||
 			 xpev->atom == clipboard)) {
 		selnotify(e);
+	} else if (xpev->state != PropertyDelete && xpev->atom == XA_WM_NAME &&
+	   embed == xpev->window) {
+		updatetitle(embed);
 	}
 }
 
@@ -767,6 +772,8 @@ createnotify(XEvent *e)
 	XReparentWindow(xw.dpy, embed, xw.win, 0, 0);
 	XSelectInput(xw.dpy, embed, PropertyChangeMask | StructureNotifyMask | EnterWindowMask);
 
+	updatetitle(embed);
+
 	XMapWindow(xw.dpy, embed);
 	sendxembed(XEMBED_EMBEDDED_NOTIFY, 0, xw.win, 0);
 
@@ -803,6 +810,44 @@ sendxembed(long msg, long detail, long d1, long d2)
 	XSendEvent(xw.dpy, embed, False, NoEventMask, );
 }
 
+Bool
+gettextprop(Window w, Atom atom, char *text, unsigned int size)
+{
+	char **list = NULL;
+	int n;
+	XTextProperty name;
+
+	if (!text || size == 0)
+		return False;
+
+	text[0] = '\0';
+	XGetTextProperty(xw.dpy, w, , atom);
+	if (!name.nitems)
+		return False;
+
+	if (name.encoding == XA_STRING) {
+		strncpy(text, (char *)name.value, size - 1);
+	} else if (XmbTextPropertyToTextList(xw.dpy, , , ) >= Success
+	   && n > 0 && *list) {
+		strncpy(text, *list, size - 1);
+		XFreeStringList(list);
+	}
+	text[size - 1] = '\0';
+	XFree(name.value);
+
+	return True;
+}
+
+void
+updatetitle(Window win)
+{
+	char name[256];
+
+	if (!gettextprop(win, xw.netwmname, name, sizeof(name)))
+		gettextprop(win, XA_WM_NAME, name, sizeof(name));
+	xsettitle(name);
+}
+
 void
 xresize(int col, int row)
 {
-- 
2.43.0

>From 73028d36e877c3c918ba96ffc95a3cc2a1b710b2 Mon Sep 17 00:00:00 2001
From: Robin Haberkorn 
Date: Sat, 3 Feb 2024 03:36:47 +0300
Subject: [PATCH 3/3] inherit window icon from embedded (Xembed) application

* This is largely taken from tabbed's "icon" patch (cf. xseticon()):
  https://tools.suckless.org/tabbed/patches/icon/
* I found that some applications that show their icon flawlessly in the WM
  won't work (neither in st, nor in tabbed).
  This was the case with SciTECO, but it could be resolved
  by reordering some statements.
* Once the embedded application terminates, we try to remove the icon again.
  `xprop` confirms that this worked.
  Unfortunately, Awesome WM will continue to show the old icon, which
  is probably an Awesome WM bug.
  Perhaps we should therefore apply this patch on top of netwmicon (FIXME):
  https://st.suckless.org/patches/netwmicon/
---
 x.c | 49 +
 1 file changed, 49 insertions(+)

diff --git a/x.c b/x.c
index 6b3a8e1..66dccc4 100644
--- a/x.c
+++ b/x.c
@@ -194,6 +194,7 @@ static void destroynotify(XEvent *e);
 static void sendxembed(long msg, long detail, long d1, long d2);
 static Bool gettextprop(Window w, Atom atom, char *text, unsigned int size);
 static void updatetitle(Window win);
+static void updateicon(Window win);
 
 static void run(void);
 static void usage(void);
@@ -520,6 +521,7 @@ propnotify(XEvent *e)
 {
 	XPropertyEvent *xpev;
 	Atom clipboard = XInternAtom(xw.dpy, "CLIPBOARD", 0);
+	Atom wmicon = XInternAtom(xw.dpy, "_NET_WM_ICON", 0);
 
 	xpev = >xproperty;
 	if (xpev->state == PropertyNewValue &&
@@ -529,6 +531,9 @@ propnotify(XEvent *e)
 	} else if (xpev->state != PropertyDelete && xpev->atom == XA_WM_NAME &&
 	   embed == xpev->window) {
 		updatetitle(embed);
+	} else if ((xpev->atom == wmicon || xpev->state == PropertyNewValue && xpev-&

Re: [dev] [st][patch] more work on the XEmbed embedder

[Robin Haberkorn]

04.02.24 12:52, Hiltjo Posthuma пишет:
> Hi,
> 
> If you want to contribute to upstream you need to rebase the patches on the
> master version of st.
> 
> Then you send the patches (git-format-patch) to the mailinglist.
> Okay. But first of all, there are remaining problems. I would like to resolve
the freeze-issue first. Secondly, this would be the wrong mailing list.
Thirdly, I doubt that the maintainers would want to merge this into mainline.

If you want to to try the patches in their current form, just build my version
or cherry-pick the commits into your own st-patch-branch.
Or does anybody insist I send them around in patch files?

[dev] [st][patch] more work on the XEmbed embedder

[Robin Haberkorn]

Hello!

I picked up the patch from Jochen Sprickerhof 
that was posted on hack...@suckless.org a few years ago, allowing you to
embed applications into st via Xembed. So this is the _host_ side of
Xembed, very similar to what tabbed does. The thing is, you do not always
want to open apps in new tabs - I personally do not use tabbed
at all - but you just want it to cover your terminal window, so it behaves
more like a fullscreen terminal application and does not spawn a new X11
window that may ruin your tiling layout etc.

Check out to the last 3 patches on this branch:
https://github.com/rhaberkorn/st/commits/patches/
(The others are really just patches I personally use for customization.)

This has been tested with SciTECO (https://github.com/rhaberkorn/sciteco),
nsxiv and mpv (--wid).
Zathura unfortunately does not work flawlessly. It does not refresh its
window once embedded. And neither does Zathura work with tabbed.

Also, st windows tend to freeze after resizing them a bit (but only while
a client is embedded).

I am not very experienced in Xlib programming, so perhaps somebody else
could have a look. Somebody who knows tabbed better than I do.

Another issue is that once an embedded app terminates, I try to remove
the icon from the st window. xprop confirms that this works.
But at least Awesome WM does not respect this change and continues
to display the old icon.
I suspect this is an Awesome WM bug.
Perhaps somebody could test with another WM.

I like this feature so much, I also looked into whether it would be
possible to somehow hack Gtk (e.g. using LD_PRELOAD) so you can
embed most Gtk applications - after all they provide GtkPlug and it
also derives from GtkWindow. Unfortunately, this would not be trivial.
It might be easier to patch Gtk itself.

All of this should perhaps eventually be part of the Wiki once
we fixed the remaining problems.

Best regards,
Robin

[bug #65232] Russian hyphenation is not working

[Robin Haberkorn]

Follow-up Comment #3, bug#65232 (group groff):

After switching from pdfroff (-Tps) to pdfmom (-Tpdf), hyphenation suddenly
works fine.

Moreover, it will even work with UTF8 input (-Kutf-8), even though that causes
other glitches. I have no idea way it can hyphenate Unicode escapes.

`pdfmom --roff -spdf` generally works much better than pdfroff, including TOC
recollation which can finally be done without manually psselect-ing thanks to
.pdfswitchtopage.

pdfroff should perhaps be marked as deprecated or pdfmom should outright
replace it.

>From my perspective, you can close this ticket.


___

Reply to this item at:

  

___
Сообщение отправлено по Savannah
https://savannah.gnu.org/

Re: PDF outline not capturing Cyrillic text

[Robin Haberkorn]

Regarding cyrillic characters in PDF outlines, I think I got a few
insights today.

It turns out that the pdfmarks in the postscript code are "text strings"
according to the PDF specs, that is either a PDFDocEncoding or
UTF-16BE with a leading byte-order marker (cf. PDF Reference 1.7).
A PDFDocEncoding is basically latin1 it seems.
This explains why the current code in MOM works with western European
languages.
Now, in order to include cyrillic, you will have to reencode whatever
encoding Groff uses and passes to the postprocessor - which will
subsequently end up in the postscript code - to UTF-16BE.
Everything needs to be hex-encoded and enclosed in sharp
brackets ().

In the most hacky case, this could be done by a script on the
postscript code generated by `pdfroff --emit-ps`. As a proof of concept
Here's an incomplete, but somewhat working version in SciTECO:

sciteco -e "16,0ED @EB/document.ps/ <@S|/Title (|; -D @I|/ D> 
@EW//"

This assumes that the Groff encoding is KOI8-R, which I chose as an
intermediate format in order to enable Russian hyphenation
(but that does not work unfortunately).
It should be rewritten into a Python or Perl script using some
iconv wrapper or ideally pdfroff itself could do it.
The script could even interpret Groff Unicode escapes generated by preconv
and convert them back to plain Unicode before writing out everything in UTF16.

I will probably just use such a hack for my purposes.

What's the status of pdfroff anyway? I read that it is more or less
deprecated and we should all use `groff -Tpdf` instead.
Actually, pdfmom should work with ms as well, actually uses
gropdf and should perform the necessary multipass processing
for pdfhref forward-references to work.
Will try this next!

Best regards,
Robin

[bug #65232] Russian hyphenation is not working

[Robin Haberkorn]

Follow-up Comment #2, bug#65232 (group groff):

Hello Branden!

I am not quite sure what additional info you need. I attached a test case. You
can reproduce it. No matter what font size or hyphenation mode, I cannot get
it to hyphenate.

Hyphenation *does* work when formatting for -Tutf8. The same is true for the
Махновщина-text from the mailing list post. Furthermore, I do not
understand why the Махновщина-text given in UTF8 can be hyphenated
correctly at all. I thought that hyphenation will only work in KOI8-R.


___

Reply to this item at:

  

___
Сообщение отправлено по Savannah
https://savannah.gnu.org/

[bug #65232] Russian hyphenation is not working

[Robin Haberkorn]

URL:
  <https://savannah.gnu.org/bugs/?65232>

 Summary: Russian hyphenation is not working
   Group: GNU roff
   Submitter: rhaberkorn
   Submitted: Ср 31 янв 2024 02:48:42
Category: Macro - others/general
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Ср 31 янв 2024 02:48:42   By: Robin Haberkorn 
I cannot get Russian hyphenation to work on a HEAD build of Groff. As far as I
understand, it should be enough to -mru. It should even enable hyphenation
mode 8 by default.

Still, I try to set HY and .hy manually without any success.

My source file UTF-8, converted to KOI8 using iconv, but I also included the
preconverted KOI8 file in case you don't have a working iconv. btw. that's a
very useful hack, as it preserves misc. codepoints as unicode character
escapes.

You have to install LiberationSerif, for instance using install-fonts.sh.

The command line to build the example used is:


iconv -f UTF-8 -t KOI8-R --unicode-subst='\[u%04X]' hyphen-utf8.ms | groff
-Tpdf -ms -mru >hyphen-koi8.pdf








___
File Attachments:


---
Name: hyphen.tar.gz  Size: 111КиБ
<http://savannah.gnu.org/bugs/download.php?file_id=55647>

AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-3112ec7181a7018604fb7b25b2201235b3bdfb6a.tar.gz

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65232>

___
Сообщение отправлено по Savannah
https://savannah.gnu.org/

Re: [Freetel-codec2] Clarifications on quantization

[Robin Haberkorn via Freetel-codec2]

Hello David,

thank you for your explanations. Everything makes a little bit more sense to me
now. I think most of the confusion comes from the fact - correct me if I am
wrong - that Codec 2 is actually a combination of Sinusoidal and LPC coding, but
in most materials you present it as a Sinusoidal coder, which is a bit 
misleading.

Let me try to sum up:

So you are basically using LPC with LSP quantization on the source signal. On
the channel you are transmitting a fixed number of LSP-coded LPC filter
coefficients instead of the variable harmonic amplitudes. It might be a bit
misleading to call this "spectral magnitudes" under Bit Allocation on the
website. (Or are LPC coefficients actually also called spectral magnitudes?)
Voicing is determined via MBE, but reduced to a single bit per 10ms.
Pitch is determined using the NLP algorithm (cf. chapter 4) and some refinement
via MBE (for which you naturally need a DFT as well).

In the decoder, a signal is synthesized using the LPC synth filter. That should
already be audible speech. But since the audio quality of pure LPC systems is
low (you write of a "mechanical quality" in your thesis), you do the following
trick: You get the DFT of the LPC-produced signal and extract the harmonic
amplitudes - but from the RMS for reasons not well understood. You then apply
the sinusoidal model (ie. "Reverse FFT"?) including phase information derived
from the voicing bits. Effectively, you are enhancing the LPC synthesized speech
by correcting the harmonic phases, resulting in increased quality.

Did I get this right?
How exactly the harmonic amplitudes are extracted, I still don't fully
understand. It's described in chapter 5.2.1, so that's my problem. Also, I do
not understand what the quantized energy information is used for.

This is not so bad for my small report, as I can outline first a pure sinusoidal
model with pros and cons, then LPC with pros and cons as an alternative and
ultimately Codec 2 as a clever synthesis of both.

I must say, that this is the most complex DSP algorithm I have seen so far, but
I presume there is equally complex stuff going on in video coding.

Best regards,
Robin Haberkorn

PS: Off-topic, but what system did you write your thesis in? Is this TeX or 
Troff?

On 9/20/23 22:14, david wrote:
> Hi Robin,
> 
>> Regarding the quantization of sinusoidal magnitudes/amplitudes, you
>> write in a
>> blog post (https://www.rowetel.com/?p=130) that the "red line" Am is
>> quantized.
>> This is not the plain frequency curve (the green one Sw). How exactly
>> do you
>> derive Am from Sw?
> 
> By sampling the LPC synthesis filter Pw=1/|A(e^jw)|^2 at each harmonic.
> 
>> But in the Harmonic Sinusoidal Model, you need to have all L
>> amplitudes
>> available to synthesize the speech signal. How is that achieved? Are
>> you simply
>> synthesizing 10 harmonics with an appropriately scaled Wo no matter
>> what?
>>
> 
> The LSPs are converted back to LPC coeffcients {ak}, which are used to
> create a LPC synthesis filter, which we sample.  Well actually we take
> the RMS value of the spectra in that band rather than sampling at the
> harmonic centre.  The blog post you linked to explains that a little
> further down, and I think it's in the thesis too.
> 
>> The fundamental frequency is determined by trying a number of
>> frequencies
>> between 50-500 Hz, determining the sinusoidal amplitudes, decoding
>> that data and
>> comparing it with the original signal? The fundamental frequency will
>> be the one
>> where that comparison yields the smallest error. This is the
>> algorithm described
>> in chapter 3.4 of your PhD thesis.
>>
> We use the non linear pitch estimation algorithm (in the thesis), the
> the MBE pitch estimator (which you outlined above) is used for
> refinement of the pitch estimate.
> 
>> What's the algorithm you are using to estimate voicing?
> 
> The MBE algorithm, but the voicing of all bands is averaged to get a
> single metric which we compare to a threshold.
> 
>> Furthermore, LPC analysis is performed directly on the speech samples
>> (time
>> domain) according to the block diagram. How does that fit together
>> with using Am
>> which is obviously a feature in the frequency domain?
> 
> The Am are extracted using freq domain techniques for the purpose of
> estimating voicing.  In the LPC quantised modes, then Am are then
> discarded and the time domain LPC are transformed to LSPs and sent to
> the decoder, where the Am are extracted.
>  
>> I do have a little bit of experience in signal/audio processing, but
>> still find
>> it hard to understand all of it. Okay I admit, I get terribly
>> confused.
> 
> Yes,

[Freetel-codec2] Clarifications on quantization

[Robin Haberkorn via Freetel-codec2]

Greetings, Dr. Rowe!

Thanks for your excellent work and for publishing it as Open Source for everyone
to study. Which I am trying to do.
I am going to give a report about Codec 2 in university and would like to
clarify a few aspects, I find hard to grasp.

Regarding the quantization of sinusoidal magnitudes/amplitudes, you write in a
blog post (https://www.rowetel.com/?p=130) that the "red line" Am is quantized.
This is not the plain frequency curve (the green one Sw). How exactly do you
derive Am from Sw?
Okay, so you use that as the input of an LPC (p=10) and the 10 LPC coefficients
are transformed to LSPs to decrease the influence of transmission errors. Also,
there will always be 10 values, no matter how much harmonics are in the signal.
You can of course determine the number of harmonics in the decoder just given
the fundamental frequency.
But in the Harmonic Sinusoidal Model, you need to have all L amplitudes
available to synthesize the speech signal. How is that achieved? Are you simply
synthesizing 10 harmonics with an appropriately scaled Wo no matter what?

The fundamental frequency is determined by trying a number of frequencies
between 50-500 Hz, determining the sinusoidal amplitudes, decoding that data and
comparing it with the original signal? The fundamental frequency will be the one
where that comparison yields the smallest error. This is the algorithm described
in chapter 3.4 of your PhD thesis.

What's the algorithm you are using to estimate voicing? I correctly understand
that you determine the voicing (1 bit: voiced or unvoiced) every 10ms (putting
two results into every frame that gets output every 20ms)?
The purpose of this information is in assisting the reconstruction of phase-data
in the decoder, esp. to get unvoiced sounds right?
At the same time, the block diagram (https://www.rowetel.com/?page_id=452)
mentions an MBE voicing estimation. How many frequency bands for MBE can there
be if the result is a single bit per 10ms chunk?

Furthermore, LPC analysis is performed directly on the speech samples (time
domain) according to the block diagram. How does that fit together with using Am
which is obviously a feature in the frequency domain?

I do have a little bit of experience in signal/audio processing, but still find
it hard to understand all of it. Okay I admit, I get terribly confused.

Best regards,
Robin Haberkorn


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

AES in GNU APL

[Robin Haberkorn]

Hello everyone!

Here's a complete implementation of AES in GNU APL, that I thought might be
worth sharing:

https://gist.github.com/rhaberkorn/78a982dbd49bc896175607289507cb64

It's purely educational and written to be as close to the FIPS 197 standard as
possible. In fact, this was a course work for a cryptography class and left the
instructor quite puzzled. ;-)
Still encryption and decryption for all standard key sizes is supported.

Getting rid of unused and trivial functions and the examples at the end, this is
a mere 47 lines.

Best regards,
Robin

ms/mm page margins too large

[Robin Haberkorn]

Hello!

I was trying to set up an ms-document with small page margins (see attachment),
but I don't seem to get below a certain limit (especially on the bottom side).
In one-column mode, the bottom border is a bit smaller, but still larger than
1cm. I also cannot explain the spacing introduced by the .2C request (between
BEFORE and AFTER). Build with

pdfroff -ms margins.ms >margins-ms.pdf

Does anybody understand what's going on?

I've tried something similar with mm (margins.mm), trying to set 1cm margins on
all sides. This doesn't work as well when built with:

pdfroff -mm -P-pa4 -rW=19c -rO=1c -rL=27.7c margins.mm >margins-mm.pdf

Although, here we can at least set the page length to something oversized like
31c to get close to what we want. A4 has a height of 29.7cm, so this is also
strange.

For my particular task, I will probably just switch from ms to mm. But it would
be nice to understand why they behave this way.

Yours sincerely,
Robin\# pdfroff -mm -P-pa4 -rW=19c -rO=1c -rL=27.7c margins.mm >margins.pdf
.PGNH
.SP 1c
BEFORE
.2C
AFTER
.
.nr i 0 1
.while \n+i<=100 \{\
.  br
.  nop \ni
.\}\# pdfroff -ms margins.ms >margins.pdf
.nr PO 1c
.nr LL 21c-\n(PO-1c
.nr HM 1c
.\" FIXME: The actual bottom border is much larger.
.nr FM 1c
.nr PI 0
.\" Disable headers and footers
.ds CH
.ds CF
.
BEFORE
.2C
AFTER
.
.nr i 0 1
.while \n+i<=100 \{\
.  br
.  nop \ni
.\}

margins-ms.pdf
Description: Adobe PDF document


margins-mm.pdf
Description: Adobe PDF document

Re: PDF outline not capturing Cyrillic text

[Robin Haberkorn]

Hello Peter,

I am also now stumbling across Cyrillc-related issues with pdfmark. I am using
ms for the time being. The bug also affects autogenerating link texts given via
`.pdfhref L`.
In the most simple case, preconv will turn your Cyrillic characters into escapes
which are apparently not further interpreted by pdfmark (or anything that 
follows).
I see text like "[u0421][u043F]..." in my outline.

I believe that this is why you have .pdfmomclean in MOM. Do I understand
correctly that this is supposed to turn the escapes back into Latin-1?
This is presumably mainly the work of .asciify, which would be misnamed anyway.
It does not work with Cyrillic at all, which doesn't surprise.
That's also why you don't get "mojibake garbage" in the outline. None of the
Cyrillic characters end up in intermediate output.

It also explains why I previously had no problems with German Unicode characters
(that was using MOM) - they can be converted back into Latin-1.

Manually editing the ps:exec lines in the intermediate output and inserting
Unicode characters there, does not produce the desired results, which is also
not surprising.

So it seems that the main problem really lies in grops and/or gropdf which
should ideally work with the Unicode escapes produced by preconv.
I am not sure if we would still need .pdfmomclean. But whatever useful stuff it
currently does, it should probably be in pdfmark.tmac (and/or pdf.tmac?) 
instead.

Best regards,
Robin

Re: Questions concerning hyphenation patterns for non-Latin languages, e.g. Russian

[Robin Haberkorn]

25.04.23 19:51, G. Branden Robinson пишет:

 While I'm pontificating I'll opine that I'm not a huge fan of C++ as
 a language, but I have found with groff that, given discipline, and
 by maintaining a clear view of its roots in C (_also_  not my
 favorite language--but one alienating, enemy-making rant at a time),
 and not picking up every f***ing new feature that gets shoved into
 the language as soon as (or before) it's standardized, it_can_  be
 managed.  But I also think that the C++ templating facility was, in
 implementation, one of the worst features ever developed for any
 programming language.


I would agree to that largely. The only acceptable C++ is the one close to C. 
Especially if you do indeed interface with C APIs. But even then it remains 
broken by design with its classes in headers, forcing you to expose every type 
belonging to your class to everybody. What's the benefit in C++, especially when 
restraining from namespaces? Deeply nested class hierarchies? You really 
shouldn't have those anyway. IMHO you can get much clearer and better isolated 
code (smaller headers anyway) with properly written idiomatic plain C code. It's 
the lesser of two evils. The preprocessor is one of those things I am also not 
happy with, although I found that C++ often pushes you to metaprogramming only 
for marginally improved typesafety compared to plain-C non-preprocessed 
solutions. As a side effect you get overblown binaries that will blow your cache 
hierarchies. On the other hand the C preprocessor could be made much more useful 
for metaprogramming with a few simple extensions...
I have not long ago migrated SciTECO from "C-like" C++ to plain C and I am not 
looking back!

Re: neatroff for Russian. (Was: Questions concerning hyphenation patterns for non-Latin languages, e.g. Russian)

[Robin Haberkorn]

Hello!

I can confirm that Neatroff (and Heirloom Troff) works well for typesetting 
Russian texts including hyphenation.
BUT, I found them unsuitable for complex scientific texts as their ms macros are 
buggy and tbl is somewhat limited. Regarding Neatroff, I found that its 
hyperlinking capabilities are extremely limited.


For future texts I therefore wanted to return to Groff (where we also have the 
excellent MOM macros). Not being able to hyphenate UTF-8 Cyrillic text is a 
major limitation for me. I might get away with converting it to KOI8 first, but 
could I still mix in Unicode characters this way (as they are considered special 
characters by Groff)?


Perhaps I will have a look at the hyphenation code and try to fix it. Hacking 
the typesetter is always a perfect distraction from the work you are supposed to 
do instead. ;-)


Yours sincerely,
Robin

26.04.23 14:10, Ralph Corderoy пишет:

Hi Oliver,

Are you aware there are other troff implementations than GNU's groff?
Neatroff is one.  Ali Gholami Rudi wrote it because he wanted better
Unicode support for foreign languages, including right-to-left text.
He seems very much of your mould in needs.

A good summary of its features is http://litcave.rudi.ir/neatroff.pdf
I see UTF-8 hyphenation files mentioned.
There's also whole-paragraph formatting and lots of other delights.
Rudi's http://litcave.rudi.ir has a Typesetting section past the initial
list of recent changes to his software.

Feel free to continue discussing neatroff here along with general troff
questions.

Re: Lambda recursions on the example of generating permutations

[Robin Haberkorn]

 lambda.
Of course, for a more general short-circuit IfElse, we could easily define an 
operator:


∇R ← (IfBranch IfElse ElseBranch) Cond
  →Cond/3
  R ← ElseBranch ⋄ →0
  R ← IfBranch
∇

Which can now be happily used everywhere, including in lambdas:

Perm ← {{↑,/X,¨¨X+(K-1) Perm¨N-X} IfElse {X} K>1 ⊣ X←⍳1+(N←⍵)-K←⍺; X; K; N}

Except, that it does not work. And I am quite clueless why...

Best regards,
Robin




On 4/3/23 20:12, Robin Haberkorn wrote:

Hello everybody,

I stumbled across an interesting little problem. I would like to generate all 
possible combinations of taking ⍺ things from a total of ⍵. The number of 
possible combinations is consequently ⍺!⍵.


Here's a straight-forward "brute force" solution:

Perm ← {(X/⍨⍺=+/¨X←(⊂2⍴⍨⍵)⊤¨⍳2*⍵) /¨ ⊂⍳⍵; X}

  2 Perm 4
 3 4  2 4  2 3  1 4  1 3  1 2
  3 Perm 4
 2 3 4  1 3 4  1 2 4  1 2 3

Unfortunately the algorithm has O(2^⍵) time and space complexity. Which is 
okay for what I am using it, but I was still curious of how this could be 
solved recursively in a lambda. I feel that simple things like this should 
have elegant solutions in GNU APL. Unfortunately this is the best I could come 
up with:


Perm ← {⍎∊('↑,/X,¨¨X+(⍺-1) Perm¨⍵-X' 'X')[1+⍺≤1] ⊣ X←⍳1+⍵-⍺; X}

At this point I was really feeling the limitations of lambdas in GNU APL. 
There apparently aren't enough means of control flow. At least I couldn't find 
a way to utilize one of APL's operators elegantly for this purpose, so I fell 
back to a computed ⍎, which feels really clumsy and is probably quite slow as 
well.


Or you write a traditional ∇ function with →... I mean you could also write 
your own ⍶IfElse⍹ operator, but due to the lack of lexical scoping this would 
be pretty useless for recursion, unless you pass in your context as ⍺ or ⍵ 
which is again very clumsy.


I would therefore claim that we are either lacking lexical scoping and/or 
built-in structured If-Else constructs. Or lambdas should simply be allowed to 
contain ⋄, new lines and →. Or I am missing something obvious. I am not sure. 
But IMHO something fundamental is missing in the language.


I am interested in hearing your thoughts.

Yours sincerely,
Robin

PS: I am not saying "I want it like in Dyalog!!!11". GNU APL is great for what 
it is and I am not ready to switch over to Dyalog yet. I particularly like two 
things about GNU APL: 1) It's FREE software. 2.) It's more conservatively 
designed than Dyalog.

Re: Lambda recursions on the example of generating permutations

[Robin Haberkorn]

Hello Jürgen,

thank you. I can confirm that the fix works.

Best regards,
Robin

04.04.23 20:47, Dr. Jürgen Sauermann пишет:

Hi Robin,

yes it is. Fixed in *SVN 1675*.

Windows files are rarely updated, for an up-to-date windows version:

install cygwin,
check out from SVN, then
./configure ; make ; sudo make install

like in GNU/Linux.

Best Regards,
Jürgen


On 4/4/23 14:20, Robin Haberkorn wrote:

Perm ← {(X/⍨⍺=+/¨X←(⊂2⍴⍨⍵)⊤¨⍳2*⍵) /¨ ⊂⍳⍵; X}

Works on v1.8-1 (the Debian package), but NOT v1.8 for Windows 
(apl-1.8-windows.zip). Also it does not work on the SVN trunk!


This version however works on the aforementioned versions:

Perm ← {(X/⍨⍺=+/¨X←(⊂2⍴⍨⍵)⊤¨⍳2*⍵) {⍺/⍵}¨ ⊂⍳⍵; X}

Which is clearly a bug.

Re: Lambda recursions on the example of generating permutations

[Robin Haberkorn]

Perm ← {(X/⍨⍺=+/¨X←(⊂2⍴⍨⍵)⊤¨⍳2*⍵) /¨ ⊂⍳⍵; X}

Works on v1.8-1 (the Debian package), but NOT v1.8 for Windows 
(apl-1.8-windows.zip). Also it does not work on the SVN trunk!


This version however works on the aforementioned versions:

Perm ← {(X/⍨⍺=+/¨X←(⊂2⍴⍨⍵)⊤¨⍳2*⍵) {⍺/⍵}¨ ⊂⍳⍵; X}

Which is clearly a bug.

03.04.23 21:12, Robin Haberkorn пишет:

Hello everybody,

I stumbled across an interesting little problem. I would like to generate all 
possible combinations of taking ⍺ things from a total of ⍵. The number of 
possible combinations is consequently ⍺!⍵.


Here's a straight-forward "brute force" solution:

Perm ← {(X/⍨⍺=+/¨X←(⊂2⍴⍨⍵)⊤¨⍳2*⍵) /¨ ⊂⍳⍵; X}

   2 Perm 4
  3 4  2 4  2 3  1 4  1 3  1 2
   3 Perm 4
  2 3 4  1 3 4  1 2 4  1 2 3

Unfortunately the algorithm has O(2^⍵) time and space complexity. Which is okay 
for what I am using it, but I was still curious of how this could be solved 
recursively in a lambda. I feel that simple things like this should have elegant 
solutions in GNU APL. Unfortunately this is the best I could come up with:


Perm ← {⍎∊('↑,/X,¨¨X+(⍺-1) Perm¨⍵-X' 'X')[1+⍺≤1] ⊣ X←⍳1+⍵-⍺; X}

At this point I was really feeling the limitations of lambdas in GNU APL. There 
apparently aren't enough means of control flow. At least I couldn't find a way 
to utilize one of APL's operators elegantly for this purpose, so I fell back to 
a computed ⍎, which feels really clumsy and is probably quite slow as well.


Or you write a traditional ∇ function with →... I mean you could also write your 
own ⍶IfElse⍹ operator, but due to the lack of lexical scoping this would be 
pretty useless for recursion, unless you pass in your context as ⍺ or ⍵ which is 
again very clumsy.


I would therefore claim that we are either lacking lexical scoping and/or 
built-in structured If-Else constructs. Or lambdas should simply be allowed to 
contain ⋄, new lines and →. Or I am missing something obvious. I am not sure. 
But IMHO something fundamental is missing in the language.


I am interested in hearing your thoughts.

Yours sincerely,
Robin

PS: I am not saying "I want it like in Dyalog!!!11". GNU APL is great for what 
it is and I am not ready to switch over to Dyalog yet. I particularly like two 
things about GNU APL: 1) It's FREE software. 2.) It's more conservatively 
designed than Dyalog.

Lambda recursions on the example of generating permutations

[Robin Haberkorn]

Hello everybody,

I stumbled across an interesting little problem. I would like to generate all 
possible combinations of taking ⍺ things from a total of ⍵. The number of 
possible combinations is consequently ⍺!⍵.


Here's a straight-forward "brute force" solution:

Perm ← {(X/⍨⍺=+/¨X←(⊂2⍴⍨⍵)⊤¨⍳2*⍵) /¨ ⊂⍳⍵; X}

  2 Perm 4
 3 4  2 4  2 3  1 4  1 3  1 2
  3 Perm 4
 2 3 4  1 3 4  1 2 4  1 2 3

Unfortunately the algorithm has O(2^⍵) time and space complexity. Which is okay 
for what I am using it, but I was still curious of how this could be solved 
recursively in a lambda. I feel that simple things like this should have elegant 
solutions in GNU APL. Unfortunately this is the best I could come up with:


Perm ← {⍎∊('↑,/X,¨¨X+(⍺-1) Perm¨⍵-X' 'X')[1+⍺≤1] ⊣ X←⍳1+⍵-⍺; X}

At this point I was really feeling the limitations of lambdas in GNU APL. There 
apparently aren't enough means of control flow. At least I couldn't find a way 
to utilize one of APL's operators elegantly for this purpose, so I fell back to 
a computed ⍎, which feels really clumsy and is probably quite slow as well.


Or you write a traditional ∇ function with →... I mean you could also write your 
own ⍶IfElse⍹ operator, but due to the lack of lexical scoping this would be 
pretty useless for recursion, unless you pass in your context as ⍺ or ⍵ which is 
again very clumsy.


I would therefore claim that we are either lacking lexical scoping and/or 
built-in structured If-Else constructs. Or lambdas should simply be allowed to 
contain ⋄, new lines and →. Or I am missing something obvious. I am not sure. 
But IMHO something fundamental is missing in the language.


I am interested in hearing your thoughts.

Yours sincerely,
Robin

PS: I am not saying "I want it like in Dyalog!!!11". GNU APL is great for what 
it is and I am not ready to switch over to Dyalog yet. I particularly like two 
things about GNU APL: 1) It's FREE software. 2.) It's more conservatively 
designed than Dyalog.

[coreboot] Re: X131e: Status, experiences and remaining problems

[Robin Haberkorn via coreboot]

20.07.19 02:08, Robin Haberkorn пишет:
>
> 2.) At some point during my experimenting, only 4 of the 8GB RAM I've 
> installed
> would be detected. This wasn't the case in the beginning, when I started out
> with a clean 4.9-build. I've attached a board status report from this time.
> Maybe somebody can see why the 2nd 4GB module is no longer detected.
> Naturally, one of the commits I later added might be responsible. If really
> necessary, I could do a git-dissect.
> 

This suddenly went away after trying out some different RAM modules and 
reinserting
the original 2x4GB modules. The full 8GB are now detected. This might indicate 
that
the module detection has never been very reliable. I will observe whether the
modules
are reliably detected from now on, although I have no reason believe so. I have
also noticed that there are possibly relevant upstream commits. Perhaps I should
rebase on master...
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] X131e: Status, experiences and remaining problems

[Robin Haberkorn via coreboot]

Hello!

I wanted to share my experiences with corebooting the X131e (Intel edition) and
hope to be able to resolve some of the remaining issues. Previously I used a
corebooted X131e Chromebook (Stout) and it worked perfectly - I didn't have any
of the issues, which I'm going to detail further down. I got the X131e Intel as
an "upgrade" and because I thought that migrating would be trivial. I'm using
the same peripherals with the Intel boards, but installed new RAM.
Turns out the stock BIOS had hardware whitelists, so that was a good pretext to
try out coreboot.

I based my build on the 4.9 release but ended up applying some X131e patches by
James Ye, which are still pending in Gerrit. The following changes on top of 4.9
to be precise:

commit b21539d2c4f57518b964949b30ebdd200a8d1f5a
Author: James Ye 
Date:   Thu Jan 24 00:18:28 2019 +1100

mb/lenovo/x131e: add function key support

Enables function keys for X131e.
SMI handler based on google/stout. ACPI code and event masks are
reverse-engineered.

The IT8518e EC of this board uses some different ACPI methods compared to 
the
regular Lenovo H8. Add an option to use the alternative set of methods.

Change-Id: Ib3a01f37a8b54889b55e92c501c9350e6c68bd57

commit 178cf723697b9d069810fd404dcabd448d136503
Author: James Ye 
Date:   Fri Feb 1 13:29:02 2019 +1100

mb/lenovo/x131e: correct USB port config

Based on schematic and register dumps.

Change-Id: I91fc47022988cfe986fb8c1ed21dc073ee7d16bc

commit 750432f7a1487175243065d95c57f9e0e6c21204
Author: James Ye 
Date:   Tue Feb 12 22:17:52 2019 +1100

mb/lenovo/x131e: enable mSATA slot

Per google/stout. Functionality untested.

Change-Id: I7cc9837f572236acac2007e95990e64c25a5d6e2

commit 151019a9d21c612834dacad649cde7aec3132844
Author: James Ye 
Date:   Sat Jan 19 18:25:44 2019 +1100

mb/lenovo/x131e: enable WWAN detection

Per schematic. Non-presence is detected correctly, but presence is untested.

Change-Id: I4cfefb06556c9d69bc8e4a4f9d112246885c253a

commit 5bdb3cd2a802b0654feeeb19471c719db62a23c4
Author: James Ye 
Date:   Sat Jan 19 18:25:04 2019 +1100

mb/lenovo/x131e: remove PMH7

This board does not have PMH7.

Change-Id: I382958f012e5f4445efc76c7f36bbdf460c29be4

commit 1cd0a5920fb93489aa1fe5b1c0be6170f88f23da
Author: James Ye 
Date:   Thu Jan 17 22:00:14 2019 +1100

mb/lenovo/x131e: add VBT

VBT was extracted from VBIOS ROM.
Tested with libgfxinit, booting SeaBIOS into Linux.

Change-Id: Ibedb43852dc9b846850e1070b84f708c847b7dbf

Here's the board-status report:
https://coreboot.org/status/board-status.html#lenovo/x131e

The EC is probably rather old, as I didn't do a BIOS upgrade before flashing
coreboot. If possible, I'd like to avoid upgrading the EC now, as that would
require extracting it from the Lenove BIOS and programming it externally. Isn't 
it?

Now regarding the remaining issues, in order of significance (for me):

1.) There are infrequent system freezes - possibly a kernel panic? - without any
visible reason in the system journal. Unfortunately, I haven't run the board
long enough on the original BIOS to judge whether this is Coreboot-specific.
At least I tried performing some SMART and memtest86 tests - to no avail.

2.) At some point during my experimenting, only 4 of the 8GB RAM I've installed
would be detected. This wasn't the case in the beginning, when I started out
with a clean 4.9-build. I've attached a board status report from this time.
Maybe somebody can see why the 2nd 4GB module is no longer detected.
Naturally, one of the commits I later added might be responsible. If really
necessary, I could do a git-dissect.

3.) The internal speakers __sometimes__ don't work after startup. They are
simply mute. I initially thought this depends on the headphones being plugged in
at boot, but there is no causal relation.
None of the thinkpad_acpi-kernel-modules' `volume_*` params have any effect.
Changing the settings of the enigmatic "ThinkPad Console Audio Control" sound
card (created if volume_mode != 2 (N/A)) does not have any audible effect at all
- even while headphones are working.
Rerouting pins with hdajackretask does not help.
Comparing Linux kernel logs (dmesg) does not yield any difference between
working and non-working boots in the output of the relevant audio drivers.

4.) My 1600Mhz DDR3 RAM supposedly runs at 666Mhz (dmidecode --type 17).
I think it's running at 1330 MHz, though. I somewhere read that 1600 Mhz CL11 is
equivalent to 1300 Mhz CL9, which could explain this.
So I guess, I simply bought crappy RAM.

5.) The Fn-keys work after the corresponding patch. But is it possible to use
the Fn-key like any other (modifier) key? I do not get separate key-down/release
events and events for any other key-presses (except for a few that have assigned
Fn-functions). That's a bit of a waste. I guess, this is an EC "feature"...

6.) I have a WWAN mPCI card (Sierra 7710). It used to be reported 

Re: [groff] Accented Cyrillic characters

[Robin Haberkorn]

Hello Ralph!

I see! Groff seems to combine composites to single code points if possible,
probably in order to better support terminals and/or software that cannot
themselves combine them. Makes sense.
But for the rest of glyphs, it should IMHO a) make sure that accentuation glyphs
have a zero-width and b) don't drop them from composite Unicode escapes. Why is
there even something like composite support, where you can even specify Unicode
points if they are always reduced to a single code point in the end?

I tried adding a line like
u0301 0 0 0xCC81
to the R font for devutf8.
But it doesn't work. How does grotty interpret the code? They are obviously not
simply UTF-8 bytes.
(Sorry, I'm not that motivated to seriously debug this in the Groff sources.
Just hoped that somebody would already know what's going on here.)

Best regards,
Robin

02.08.2018 17:26, Ralph Corderoy пишет:
> Hello Robin!
> 
>> Currently, I'm just adding a standalone UTF composite accent character
>> (U+0301) after every vowel I want to show stress on since Unicode does
>> not seem to define separate codepoints for all of the Cyrillic
>> accented vowels.
> 
> That's the recommendation in
> https://en.wikipedia.org/wiki/Cyrillic_script_in_Unicode
> 
>> the terminal emulator (at least URXVT) will combine the accent and the
>> vowel into a single glyph.
> 
> xterm(1) does too.  libvte-based terminals seem to place it on the line
> above!?
> 
>> This approach of adding accents causes problems with tbl, though. The
>> combination of the two characters into a single glyph screws up tbl's
>> (and/or Groff's) assumptions. For instance, in a table like:
>> | саморазруше́ние |
>> | foo bar |
>> the bars won't properly line up.
> 
> It boils down to persuading `\w', used by tbl(1), that the U+0301 takes
> no space.
> 
> $ groff -Tutf8 >/dev/null
> .nr w \w'A'   
> .tm \nw 
> 24
> .nr w \w'\[u0435]'
> .tm \nw 
> 24 
> .nr w \w'\[u0435]\[u0301]'
> .tm \nw  
> 48 
> $
> 
> Tricks like overstrike with `\o' and moving left with \h affect the \w
> but don't give the desired output because grotty(1) also processes them.
> 
>> For instance, \[u0435_0301] should theoretically also format as an
>> accented Cyrillic e.  But what happens instead is that the accent is
>> dropped during formatting.  Curiously, this works when using latin
>> characters. For instance, \[e u0301], \[e aa], \[e '] will result in a
>> properly accented latin e.
> 
> I think those are mapped onto their Unicode rune, and as you start by
> saying, then isn't one for U+0435 combined with U+0301.
> 
> $ cd /usr/share/groff/1.22.3/font/devutf8
> $ grep 0435 R
> u0435_030024  0   0x0450
> u0435_030824  0   0x0451
> u0435_030624  0   0x04D7
> $ grep '0045.*0301' R 
> u0045_0301  24  0   0x00C9
> u0045_0304_0301 24  0   0x1E16
> u0045_0302_0301 24  0   0x1EBE
> $
> 
> I look forward to solutions and workarounds from the others here.  :-)
> 

[groff] Accented Cyrillic characters

[Robin Haberkorn]

Hello!

I'm working on a small Russian offline dictionary that formats the entries of
words into Troff/Man pages, so you can view them in the terminal.

There is a small problem when trying to format accented Cyrillic characters.
Accents are commonly used in Russian to highlight word stress by placing them on
the stressed syllable's first vowel.
Currently, I'm just adding a standalone UTF composite accent character (U+0301)
after every vowel I want to show stress on since Unicode does not seem to define
separate codepoints for all of the Cyrillic accented vowels.
AFAIK, the accent is not really interpreted by Groff - to it, it will seem like
a standalone glyph. But the terminal emulator (at least URXVT) will combine the
accent and the vowel into a single glyph.
For instance саморазруше\[u0301]ние will effectively render as саморазруше́ние.

This approach of adding accents causes problems with tbl, though. The
combination of the two characters into a single glyph screws up tbl's (and/or
Groff's) assumptions. For instance, in a table like:
| саморазруше́ние |
| foo bar |
the bars won't properly line up.
It will probably cause other more subtle formatting issues as well, but that's
where I personally caught it.

I tried to use the Groff Unicode composite syntax, so it becomes clear to Groff
that the accented character is a single glyph. For instance,
\[u0435_0301] should theoretically also format as an accented Cyrillic e.
But what happens instead is that the accent is dropped during formatting.
Curiously, this works when using latin characters. For instance, \[e u0301],
\[e aa], \[e '] will result in a properly accented latin e.

Why is that so? Did I catch a grotty bug here?
Do you know any workaround I could employ?

Best regards,
Robin

[Groff] gpresent (presentation macros) forked

[Robin Haberkorn]

Hi,

just wanted to inform you that I forked the gpresent macros by Bob Diertens:

https://github.com/rhaberkorn/gpresent

I did this out of sheer necessity, as I needed to prepare a few
presentations. This fork contains a hard-to-find patch, so it runs with
recent versions of Groff and adds the TITLEFORMAT and SUBTITLEFORMAT
macros. I might add other features if I need to prepare more slides.
gropdf support would be nice I guess...

Best regards,
Robin

PS: Might be of interest for the curious: SciTECO recently introduced
its own Groff postprocessor/driver (grosciteco) which can render into a
SciTECO buffer. This is used for SciTECO's integrated help system which
actually uses Groff as its markup language.



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

[Robin Haberkorn]

Hi Thomas,

On 12.02.2015 22:39, Thomas Jarosch wrote:
 ...
 
 I've reviewed and applied the 01-cbusx.patch.
 Thanks for this high quality contribution.
 
Thank you for applying it!

 How did you generate the patch file? Using Write commit to file in gitk?
 Please use git format-patch HEAD~XXX the next time. Then I can just
 apply them via git am without manually copying the commit msg etc. over.
 
No, I'm not using stupid Git GUIs :-)
Simply used `git show foo.patch`, assuming you want to apply it like a
regular patch file.
I rebased the ftdi_eeprom --device patch on top of libftdi's current
master branch and I'm attaching it here again in git-format-patch style.

 Regarding the ftdi_eeprom patch: It alters the current behavior.
 If someone uses --erase together with --flash, it is no longer possible.
 Imagine someone wants to flash a shorter eeprom than
 the one that's currently on the chip, then --erase
 is really helpful to ensure there's no garbage left.
 
 What do you think?
 
I'm not sure if erasing before flashing makes any sense. Is it even
possible for the EEPROM size to change on one chip?

Nevertheless, my patch does not really affect ftdi_eeprom's behaviour in
this regard as ftdi_eeprom used the following check on command-line
arguments in 1162549f which effectively limits you to performing a
single command per ftdi_eeprom invocation:

if (argc != 2  argc != 3)
{
printf(Syntax: %s [commands] config-file\n, argv[0]);
printf(Valid commands:\n);
printf(--read-eeprom  Read eeprom and write to -filename- from
config-file\n);
printf(--erase-eeprom  Erase eeprom\n);
printf(--flash-eeprom  Flash eeprom\n);
exit (-1);
}

What the patch changes is allowing an arbitrary number of parameters so
that the optional --device option can be supported.

So I see no reason not to apply it.

 Cheers,
 Thomas
 
Regards,
Robin

 
 --
 libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
 To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   
 

-- 
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

haberk...@metratec.com
www.metratec.com


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   From a3508896c3823d11dd9340e975d3918687a70cdc Mon Sep 17 00:00:00 2001
From: Robin Haberkorn haberk...@metratec.com
Date: Tue, 27 Jan 2015 22:53:41 +0100
Subject: [PATCH] ftdi_eeprom: added --device option to specify FTDI device

 * previously, the device could only be selected using the vendor_id,
   product_id and default_pid config file options.
   This did not guarantee that a device could be uniquely identified
   (e.g. there could be multiple devices with the same VID/PID).
   Also this severely limited the possibilities of changing a device's
   VID/PID using ftdi_eeprom - this only worked if the device happened
   to have FTDI's VID 0x0403 and a PID equal to default_pid.
 * If the --device option is omitted, ftdi_eeprom defaults to the
   old behaviour of using the config file options.
 * The order of arguments is insignificant. If multiple
   'command' options (--read-eeprom, --erase-eeprom, --flash-eeprom)
   are given, only the last one will determine the action.
---
 ftdi_eeprom/main.c | 109 -
 1 file changed, 75 insertions(+), 34 deletions(-)

diff --git a/ftdi_eeprom/main.c b/ftdi_eeprom/main.c
index c19d111..5799c71 100644
--- a/ftdi_eeprom/main.c
+++ b/ftdi_eeprom/main.c
@@ -145,6 +145,20 @@ static void eeprom_get_value(struct ftdi_context *ftdi, enum ftdi_eeprom_value v
 }
 }
 
+static void usage(const char *program)
+{
+fprintf(stderr, Syntax: %s [...options...] config-file\n, program);
+fprintf(stderr, Valid Options:\n);
+fprintf(stderr, --device description  Specify device to open by decription string. One of:\n);
+fprintf(stderr,  d:devicenode\n);
+fprintf(stderr,  i:vendor:product\n);
+fprintf(stderr,  i:vendor:product:index\n);
+fprintf(stderr,  s:vendor:product:serial\n);
+fprintf(stderr, --read-eeprom   Read eeprom and write to -filename- from config-file\n);
+fprintf(stderr, --erase-eeprom  Erase eeprom\n);
+fprintf(stderr, --flash-eeprom  Flash eeprom\n);
+}
+
 int main(int argc, char *argv[])
 {
 /*
@@ -205,14 +219,20 @@ int main(int argc, char *argv[])
 /*
 normal variables
 */
-int _read = 0, _erase = 0, _flash = 0;
+enum {
+COMMAND_READ = 1,
+COMMAND_ERASE,
+COMMAND_FLASH
+} command = 0;
+const char *cfg_filename = NULL;
+const char *device_description = NULL;
 
 const int max_eeprom_size = 256;
 int my_eeprom_size = 0;
 unsigned char *eeprom_buf = NULL;
 char *filename;
 int size_check;
-int i, argc_filename;
+int i

Re: [PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

[Robin Haberkorn]

Hi,

On 28.01.2015 07:42, Paul Fertser wrote:
 Hi,
 
 ...
 
 Unless when you say pull request you do not mean git-request-pull(1)
 but the unique non-standard proprietary github pullrequest which
 would force the maintainers to use github webui to do their work and
 depend on a single commercial entity.
 
Yes, that's exactly what I mean. It's a little bit more convenient with
Github and you get a ticket system. Sending git-request-pull mails or
patches does of course work as well. It would also still work if you had
a Github mirror. It would be just another way to receive contributions
and draw attention to the project.
But this is not very important to me. It was only a suggestion.

Best regards,
Robin

-- 
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

haberk...@metratec.com
www.metratec.com

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   

[PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

[Robin Haberkorn]

Hello,

ftdi_eeprom currently does not allow you to specify the FTDI device
reliably/uniquely, nor is reflashing of the VID/PID allowed in every case.

I attached a patch (02-ftdi_eeprom_device_selection.patch) fixing this.
It applies on top of the last patch I sent, which I'm attaching here
again for convenience (01-cbusx.patch).

Best regards,
Robin

btw.: Hosting a Github mirror of the libftdi repository could boost free
software contributions to libftdi. With a Github repository, I could
create a fork and maintain my patches on a public branch, while
sending you pull requests. You could then merge it into the mirror
repository and pull changes from the mirror into the upstream repository.

-- 
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

haberk...@metratec.com
www.metratec.com


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   commit e45f0dbca5ee854a159d7e9cecc5f6a7ffa6f3c1
Author: Robin Haberkorn haberk...@metratec.com
Date:   Wed Jan 14 00:03:38 2015 +0100

fixed ftdi_cbus_func and ftdi_cbush_func enumerations and introduced ftdi_cbusx_func

 * removed CBUS_BB. D2XX doesn't have it, so I don't think it's actually valid.
 * CBUSH_TXLED/CBUSH_RXLED had the wrong values probably because the author
   looked at an outdated D2XX ftdi.h
   These values were also wrong in various mux tables of ftdi.c resulting
   e.g. in confusing outputs of the eeprom.c example.
 * ftdi_cbush_func was extended to contain FT230X CBUS functions.
   However, the clock functions are different on FT-X and it is also
   confusing to use CBUSH constants on FT-X chips, so I introduced another
   enum ftdi_cbusx_func with CBUSX constants.
 * Added support for setting CBUS functions on FT232H and FT230X in ftdi_eeprom.
   To support these chips, special cbushN and cbusxN options have been
   introduced.
   Possible values of the cbus options now match the ftdi.h constant names.
   Libconfuse string lists are no longer used as option types since they do not
   represent enumerations but lists.
 * When cbus options are missing in ftdi_eeprom config files, keep the
   chip defaults as set by ftdi_eeprom_initdefaults().

diff --git a/ftdi_eeprom/example.conf b/ftdi_eeprom/example.conf
index 2c50fda..28d1702 100644
--- a/ftdi_eeprom/example.conf
+++ b/ftdi_eeprom/example.conf
@@ -24,6 +24,34 @@ suspend_pull_downs=false	# Enable suspend pull downs for lower power
 change_usb_version=false	# Change USB Version
 usb_version=0x0200		# Only used when change_usb_version is enabled
 
+# Only used on FT-R chips (when omitted, use chip defaults)
+# Possible values correspond to enum ftdi_cbus_func.
+cbus0=TXLED
+cbus1=RXLED
+cbus2=TXDEN
+cbus3=PWREN
+cbus4=SLEEP
+
+# Only used on FT232H chips (when omitted, use chip defaults)
+# Possible values correspond to enum ftdi_cbush_func.
+cbush0=TRISTATE
+cbush1=TRISTATE
+cbush2=TRISTATE
+cbush3=TRISTATE
+cbush4=TRISTATE
+cbush5=TRISTATE
+cbush6=TRISTATE
+cbush7=TRISTATE
+cbush8=TRISTATE
+cbush9=TRISTATE
+
+# Only used on FT230X chips (when omitted, use chip defaults)
+# Possible values correspond to enum ftdi_cbusx_func.
+cbusx0=TXDEN
+cbusx1=RXLED
+cbusx2=TXLED
+cbusx3=SLEEP
+
 
 # Misc #
 
diff --git a/ftdi_eeprom/main.c b/ftdi_eeprom/main.c
index 2592796..c19d111 100644
--- a/ftdi_eeprom/main.c
+++ b/ftdi_eeprom/main.c
@@ -41,27 +41,72 @@
 #include ftdi.h
 #include ftdi_eeprom_version.h
 
-static int str_to_cbus(char *str, int max_allowed)
+static int parse_cbus(cfg_t *cfg, cfg_opt_t *opt, const char *value, void *result)
 {
-#define MAX_OPTION 14
-const char* options[MAX_OPTION] =
+static const char* options[] =
 {
-TXDEN, PWREN, RXLED, TXLED, TXRXLED, SLEEP,
-CLK48, CLK24, CLK12, CLK6,
-IO_MODE, BITBANG_WR, BITBANG_RD, SPECIAL
+TXDEN, PWREN, RXLED, TXLED, TXRXLED, SLEEP, CLK48,
+CLK24, CLK12, CLK6, IOMODE, BB_WR, BB_RD
 };
+
 int i;
-max_allowed += 1;
-if (max_allowed  MAX_OPTION) max_allowed = MAX_OPTION;
-for (i=0; imax_allowed; i++)
+for (i=0; isizeof(options)/sizeof(*options); i++)
 {
-if (!(strcmp(options[i], str)))
+if (!(strcmp(options[i], value)))
 {
-return i;
+*(int *)result = i;
+return 0;
 }
 }
-printf(WARNING: Invalid cbus option '%s'\n, str);
-return 0;
+
+cfg_error(cfg, Invalid %s option '%s', cfg_opt_name(opt), value);
+return -1;
+}
+
+static int parse_cbush(cfg_t *cfg, cfg_opt_t *opt, const char *value, void *result)
+{
+static const char* options[] =
+{
+TRISTATE, TXLED, RXLED, TXRXLED, PWREN, SLEEP,
+DRIVE_0, DRIVE1, IOMODE, TXDEN, CLK30, CLK15, CLK7_5
+};
+
+int i;
+for (i=0; isizeof(options)/sizeof(*options); i

Re: [PATCH] FT232R and FT245R EEPROM user area size check

[Robin Haberkorn]

Hi Jim,

On 15.01.2015 02:35, Jim Paris wrote:

Hi Robin,

See doc/EEPROM-structure, and git commit a45ea32b4ffd.  I believe the
existing code intentionally goes against what AN_121 describes, as
written in that doc.


After some investigation, I think there's a misunderstanding.
Yes, it appears as if 4 bytes after the serial number are reserved. This 
means that the statement in AN121 Start Address = the address following 
the last byte of SerialNumber string. is wrong.


However, I think there's still 96 bytes of user area since it all adds 
up nicely -- the 4 extra bytes appear to be aken care of arleady in the 
48 word user area as stated by AN121.

There are 128 bytes of internal EEPROM in total (AN121).
The descriptive strings begin at byte 0x1C (=28) in the EEPROMs I have 
at hand (both written with FTProg and ftdi_eeprom).


28 + 48*2 + 4 = 128

Also I found out about this because I wanted to reproduce an EEPROM 
written originally with FT Prog using ftdi_eeprom. The strings initially 
written by FT Prog (45 characters) turned out to be 1 character (2 
bytes) too long for libftdi's userarea space check (which was 88 bytes = 
44 words).


With FT Prog I can write up to 48 characters which is exactly what 
AN121 states.
If FT Prog (which I assume is based on FTD2XX) doesn't get it right, 
who does?



Either way, the _230X is decribed in its datasheet sa having an
identical EEPROM structure as the _R, so any patch that treats them
differently is probably not correct.


You mean this datasheet:
http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT230X.pdf

It does not say its EEPROM/MTP layout is identical to type-R chips.
It does say:
The MTP memory on all FT-X devices can be programmed over USB. This 
method is the same as for the EEPROM on other FTDI devices such as the 
FT232R. (p.33)


It does not give any details about the EEPROM/MTP memory layout, not to 
mention about the available user area space.


Perhaps the other chip's user area space checks in libftdi should also 
be reviewed, based on what FT Prog or FT_EE_UASize() reports.




Jim



Best regards,
Robin

--
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

haberk...@metratec.com
www.metratec.com

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   

Re: suspect typo and submission of demonstration application

[Robin Haberkorn]

Hi,

On 14.01.2015 11:42, Thomas Jarosch wrote:

Hello Rodney,

On Thursday, 8. January 2015 10:35:14 Rodney Sinclair wrote:

The following appears to be a typo on the Python interface for the FT230X:

CBUSG_DRIVE1 should probably be CBUSH_DRIVE_1



True. I also fixed that in the patch I sent yesterday. Also I didn't 
mention it. Sorry :-)



The attached Python script demonstrates how to set the maximum current
and to configure one of the CBUS pins on an FT230X.


thanks for the hint about the typo, it's actually wrong in the libftdi
header file. At first I thought about introducing a compat enum entry,
but given that this has never been spotted before, I don't think it's worth
the effort.

Regarding the example application: The license says it's
released to the public. Is your intention to license it
as the same license as libftdi (GPL v2)?

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com



--
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

haberk...@metratec.com
www.metratec.com

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   

Re: suspect typo and submission of demonstration application

[Robin Haberkorn]

Hi Thomas,

the last patch I've sent breaks backward compatibility somewhat. 
Especially since CBUSG_DRIVE1 was renamed to CBUSH_DRIVE1. If 
compatibility matters, we can add a deprecated CBUSG_DRIVE1 constant/define.


Also, the larger function codes (for FT-X) have their own enum now. But 
since the ftdi_cbush_function enum was not very well suited for setting 
CBUS functions on FT230X and it was extended only recently, I doubt that 
many people rely on the old constants.


Regarding the `ftdi_eeprom` changes: Setting CBUS functions on FT232H 
and FT230X was not really possible in v1.2 -- at least not without 
hacking. Also, to find out that ftdi_eeprom even supports that means you 
would have had to read its source code as it wasn't documented.
On the other hand, I also renamed the CBUS function names for the 
cbusN options on type R chips, so they match the ftdi.h constant names.
So yes, even setting CBUS function codes on type R chips with 
ftdi_eeprom is not backwards compatible after applying my patch.


Another change in ftdi_eeprom was to flash the chip-specific CBUS 
function defaults, unless overwritten by one of the cbusN, cbushN or 
cbusxN options. However I don't see how anyone could desire the old 
behaviour of overwriting the CBUS functions if these options are not 
specified. Together with the inability to set the CBUS functions on 
FT232H and FT230X chips properly, this old behaviour seriously limited 
ftdi_eeprom's usefulness on these chips.


Best regards,
Robin

On 14.01.2015 17:14, Thomas Jarosch wrote:

Hi Robin,

On Wednesday, 14. January 2015 17:09:26 Robin Haberkorn wrote:

On 14.01.2015 11:42, Thomas Jarosch wrote:

Hello Rodney,

On Thursday, 8. January 2015 10:35:14 Rodney Sinclair wrote:

The following appears to be a typo on the Python interface for the

FT230X:

 CBUSG_DRIVE1 should probably be CBUSH_DRIVE_1


True. I also fixed that in the patch I sent yesterday. Also I didn't
mention it. Sorry :-)


I have to take a closer look at your two patches the next days,
especially regarding backward compatibility.

Regarding your other question: The mailinglist is
the right place to post patches :)

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com



--
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

haberk...@metratec.com
www.metratec.com

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   

[PATCH] EEPROM CBUS function fixes and ftdi_eeprom support

[Robin Haberkorn]

Hi again,

you find attached a patch that applies to libftdi's master branch.
It fixes and cleans up the CBUS function constants and adds FT232H as 
well as FT230X CBUS function config support to the ftdi_eeprom tool.


This will actually allow you to program the CBUS functions on a FT230X 
in a way that matches what FT Prog does. The eeprom.c example will 
also now display the correct values on this chip.

See the patch file's comment for more details.

One thing I'm not sure about: I removed the CBUS_BB constant as FTDI's 
ftd2xx.h has nothing like it. But I haven't read the type R's data 
sheets. If there is indeed any use for this constant, just tell me and I 
will revise this patch.


Best regards,
Robin Haberkorn

btw.: Is this mailing list the preferred way of sending patches? Is 
there any official Github mirror I can send pull requests to?


--
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

haberk...@metratec.com
www.metratec.com


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   commit e904e9db37bebe98eb005d1f148fac0a63ee6e08
Author: Robin Haberkorn haberk...@metratec.com
Date:   Wed Jan 14 00:03:38 2015 +0100

fixed ftdi_cbus_func and ftdi_cbush_func enumerations and introduced ftdi_cbusx_func

 * removed CBUS_BB. D2XX doesn't have it, so I don't think it's actually valid.
 * CBUSH_TXLED/CBUSH_RXLED had the wrong values probably because the author
   looked at an outdated D2XX ftdi.h
   These values were also wrong in various mux tables of ftdi.c resulting
   e.g. in confusing outputs of the eeprom.c example.
 * ftdi_cbush_func was extended to contain FT230X CBUS functions.
   However, the clock functions are different on FT-X and it is also
   confusing to use CBUSH constants on FT-X chips, so I introduced another
   enum ftdi_cbusx_func with CBUSX constants.
 * Added support for setting CBUS functions on FT232H and FT230X in ftdi_eeprom.
   To support these chips, special cbushN and cbusxN options have been
   introduced.
   Possible values of the cbus options now match the ftdi.h constant names.
   Libconfuse string lists are no longer used as option types since they do not
   represent enumerations but lists.
 * When cbus options are missing in ftdi_eeprom config files, keep the
   chip defaults as set by ftdi_eeprom_initdefaults().

diff --git a/ftdi_eeprom/example.conf b/ftdi_eeprom/example.conf
index 2c50fda..28d1702 100644
--- a/ftdi_eeprom/example.conf
+++ b/ftdi_eeprom/example.conf
@@ -24,6 +24,34 @@ suspend_pull_downs=false	# Enable suspend pull downs for lower power
 change_usb_version=false	# Change USB Version
 usb_version=0x0200		# Only used when change_usb_version is enabled
 
+# Only used on FT-R chips (when omitted, use chip defaults)
+# Possible values correspond to enum ftdi_cbus_func.
+cbus0=TXLED
+cbus1=RXLED
+cbus2=TXDEN
+cbus3=PWREN
+cbus4=SLEEP
+
+# Only used on FT232H chips (when omitted, use chip defaults)
+# Possible values correspond to enum ftdi_cbush_func.
+cbush0=TRISTATE
+cbush1=TRISTATE
+cbush2=TRISTATE
+cbush3=TRISTATE
+cbush4=TRISTATE
+cbush5=TRISTATE
+cbush6=TRISTATE
+cbush7=TRISTATE
+cbush8=TRISTATE
+cbush9=TRISTATE
+
+# Only used on FT230X chips (when omitted, use chip defaults)
+# Possible values correspond to enum ftdi_cbusx_func.
+cbusx0=TXDEN
+cbusx1=RXLED
+cbusx2=TXLED
+cbusx3=SLEEP
+
 
 # Misc #
 
diff --git a/ftdi_eeprom/main.c b/ftdi_eeprom/main.c
index 2592796..c19d111 100644
--- a/ftdi_eeprom/main.c
+++ b/ftdi_eeprom/main.c
@@ -41,27 +41,72 @@
 #include ftdi.h
 #include ftdi_eeprom_version.h
 
-static int str_to_cbus(char *str, int max_allowed)
+static int parse_cbus(cfg_t *cfg, cfg_opt_t *opt, const char *value, void *result)
 {
-#define MAX_OPTION 14
-const char* options[MAX_OPTION] =
+static const char* options[] =
 {
-TXDEN, PWREN, RXLED, TXLED, TXRXLED, SLEEP,
-CLK48, CLK24, CLK12, CLK6,
-IO_MODE, BITBANG_WR, BITBANG_RD, SPECIAL
+TXDEN, PWREN, RXLED, TXLED, TXRXLED, SLEEP, CLK48,
+CLK24, CLK12, CLK6, IOMODE, BB_WR, BB_RD
 };
+
 int i;
-max_allowed += 1;
-if (max_allowed  MAX_OPTION) max_allowed = MAX_OPTION;
-for (i=0; imax_allowed; i++)
+for (i=0; isizeof(options)/sizeof(*options); i++)
 {
-if (!(strcmp(options[i], str)))
+if (!(strcmp(options[i], value)))
 {
-return i;
+*(int *)result = i;
+return 0;
 }
 }
-printf(WARNING: Invalid cbus option '%s'\n, str);
-return 0;
+
+cfg_error(cfg, Invalid %s option '%s', cfg_opt_name(opt), value);
+return -1;
+}
+
+static int parse_cbush(cfg_t *cfg, cfg_opt_t *opt, const char *value, void *result)
+{
+static const char* options[] =
+{
+TRISTATE, TXLED, RXLED, TXRXLED, PWREN, SLEEP

[Groff] [mom][patch] multipage boxed tables

[Robin Haberkorn]

Dear groffers,

I ported the ms package's tbl macros, specifically the multipage boxed
table support, to Mom.
It appears to work fine so far, but I'm neither a groff nor a -ms guru yet.
There are possibly some bugs that could be easily avoided by someone
who is more familiar with the ms macros.
That's why I'm writing you this - instead of mailing it to Peter directly.

For instance, why does the tbl@print-header macro change the
environment before printing the diversion? Shouldn't be everything
already be formatted in an environment-independent way when the
diversion is created? Or do I have to expect transparent throughputs
(\! and the like) generated by tbl? What exactly is in a diversion -
after all it's not a macro?
Also have a look at the other comments I added.

See attached patch. It's diffed against CVS HEAD.

Best regards,
Robin


multipage_boxed_tbl.patch
Description: Binary data

[Groff] [mom][patch] FLOAT bug fixes

[Robin Haberkorn]

Dear groffers,

I have found and fixed two severe mom bugs in the FLOAT macro. See
attachment - it's a patch against CVS HEAD.

1) if a FLOAT FORCE block fits on the current page, the register
#FORCE is not removed/reset. If it does not fit on the page, a NEWPAGE
is emitted and #FORCE is removed.
This results in the FLOAT immediately following a forced FLOAT
(fitting on its page) being treated as a forced FLOAT as well, even if
it isn't a forced FLOAT. I think Peter will understand...

2) forced FLOATs that do NOT fit on the current page are formatted
strangely. At least if they contain `pic`-processed code, the picture
is formatted at very top of the new page with everything else (like
captions from the same FLOAT and running text) being layed over the
picture.
Apparently the diversion (FLOAT*DIV) cannot be reproduced properly
after breaking to the new page. I could not find the root cause of
this, but perhaps it has something to do with \n[dn] being reset after
the NEWPAGE call. Restoring \n[dn] after NEWPAGE doesn't help though.
I worked around this. Instead of emitting the FLOAT*DIV in the FLOAT
macro call for forced FLOATs that do not fit on their page, I let them
be added to the deferred float list (FLOAT*DIV:\n[defer]), just like
ordinary deferred FLOATs, and then issue a NEWPAGE.
The forced FLOAT will then be printed properly by the HEADER trap.

I'm in a hurry, so no test case this time. If you do need one, just say so.

Best regards,
Robin


float_fixes.patch
Description: Binary data

[Groff] [mom][bug][patch] NUMBER_LINES and tbl

[Robin Haberkorn]

Hi everyone,

found and fixed another bug in the mom macros.
Her handling of NUMBER_LINES if tbl is used was buggy.
If you used NUMBER_LINES to turn on line numbering, turned it off and
then used tbl tables, the table was numbered. Naturally if you resumed
line numbering after the table, line numbers were wrong.

My system:
Linux 3.2.0-52-generic #78-Ubuntu SMP Fri Jul 26 16:21:44 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

GNU grops (groff) version 1.22.2
GNU troff (groff) version 1.22.2

I was using mom v2.0-a1 as well as the CVS HEAD of om.tmac.

The reason was that tbl apparently evaluates \n[ln] to determine
whether line numbering is active or not - but I do not fully
understand the bulk of troff requests tbl spits out.
Nevertheless, mom's NUMBER_LINES OFF stopped line numbering but did
not reset register ln (tbl expects 0).
`ln' however is important for restarting line numbering with
NUMBER_LINES RESUME via .nm +0.

The attached tarball contains a test case (linenumber_tbl_bug.mom),
how it looked like (linenumber_tbl_bug.pdf), my patch against CVS HEAD
(linenumber_tbl_bug.patch) and how it looks fixed
(linenumber_tbl_bug_fixed.pdf).

cheers,
Robin

btw. I have a whole list of mom bugs, so expect patches and more bug
reports soon.


linenumber_tbl_bug.tar.gz
Description: GNU Zip compressed data

Re: [Groff] refer, mom and inline references

[Robin Haberkorn]

Hello Peter,

2013/8/11 Peter Schaffter pe...@schaffter.ca:
 ...
 At the top of your file,

   .R1
 label (A.n|Q) ', ' D.y
 bracket-label  ( )\c 
 join-authors , and  ,  , and 
 reverse A1
 sort A1Q1T1B1E1
 database path to database
   .R2

 With this setup, references entered without a preceding .REF are
 inserted into running text.  For example,

   end of sentence
   .[
   keywords
   .]
   \. A new sentence.

Works like a charm, thanks!

 will produce end of sentence (author's last name, date). A new
 sentence.

 To add a page or page-range number

   end of sentence
   .[
   [ keywords
   .], p. 168)\c
   \. A new sentence.

 will produce end of sentence (author's last name, date, p. 168). A
 new sentence.

Now I see why there are bracket flags :-)


 is all that's required.  There's no need for an additional refer
 block.

 Hope this helps.

Yes, that works very well.
I wonder why I thought I'd need custom .]- and .][ macros since refer
inserts the labels just fine on its own.
Turns out, the \c at the EOL before my citation blocks somehow
suppressed the entire label automatically inserted by refer.
Strange groff world...

Best regards,
Robin

[Groff] refer, mom and inline references

[Robin Haberkorn]

Hello,

I know a lot has been written on this mailing list about refer and its
mom integration.
However, I still don't quite get it.
Currently I'm writing my bachelor thesis in groff -mom. It was
relatively easy to imitate the LaTex template they were providing,
including Computer Modern fonts and so on but I'm still struggling
with refer.
I would like to have inline references in an abbreviated form (like
[AUTHORYEAR]) and a bibliography with all references automatically
collected.

As I understand mom's refer support and as I was able to verify it,
mom provides the following possibilities:
 * footnote references
 * endnote references
 * inline references
 * bibliographies

When I use endnote references, mom will merely insert a small
superscript number into the running text.
When I use inline references my references are put inline with no
apparent way of customizing the inline citation style.
When I use a .BIBLIOGRAPHY and refer's accumulate option, my
references are neatly accumulated into the bibliography but no longer
occur inline, neither with .REF, nor with .REF[. I guess this has
something to do with refer no longer emitting the start/end reference
macros and string definitions for mom to format.

Any pointers on how to achieve what I want?

Would I be able to at least get automatically formatted inline
references in the [AUTHORYEAR] style using refer's label feature with
a *manually* populated bibliography?
I guess I would have to write custom .[- and .][ macros and bypass
mom's .REF macros altogether.

Best regards,
Robin

[Groff] quick and dirty preprocessors: htbl.tes

[Robin Haberkorn]

Hi,

one thing I like about groff/troff is the ability to quickly write
preprocessors extending troff.
I wrote one as part of SciTECO -- in the SciTECO language:
https://github.com/rhaberkorn/sciteco/blob/master/doc/htbl.tes
(Note: contains control codes not properly displayed by Github)
It's a drop-in replacement for tbl, that emits HTML tables for
processing with grohtml.
The code is horrible (it was hacked interactively and then turned into
a batch script), and it only supports a subset of tbl, that is exactly
what I used in the SciTECO manpage tables.
It can be seen in action here:
http://rhaberkorn.github.io/sciteco/manuals/sciteco.7.html

I've also written a small preprocessor in csnobol4 that pipes
.HIGHLIGHT blocks in your groff -mom code through GNU
source-highlight, effectively giving you syntax highlighting for
inline code blocks and an UML preprocessor that pipes .UML blocks into
PlantUML and inserts .PDF_IMAGE references in its place.
Anyone interested in these?

Best regards,
Robin

Re: [Groff] refer, mom and inline references

[Robin Haberkorn]

2013/8/9 jjbrioist jean.brio...@numericable.fr:
 Le vendredi 09 août 2013 à 17:35 +0200, Robin Haberkorn a écrit :
 Hello Robin,

 I was facing the same issue as you, although I am using -ms for the time.
 I use the -S option to get inline references.

 Assume you have the following entry in your
 xxx.bib file :

 %A John Robert
 %T Measuring steel bar tension using X-rays
 %D 1993
 %K X-rays dynamometer steel
 %L Steel Res. 35
 %R Steel Res.
 %N 35
 %I Springer
 %C Cleveland


 and your text reads something like

 .BD
 Lately my life
  .[[
 Robert
  .]]
 has become more complicated.
 .R
 .DE
 .LP

 (take care of the double brackets). Compile this with

 refer -pxxx.bib -e -S thesis.ms  aux.ms
 groff -ms aux.ms  thesis.ps


Hello Jean,

I wonder how this could work. Perhaps -ms implementations of ]- and ][
do the label insertion appropriately.
The manual refer preprocessing however is definitely not necessary
since refer -S is just a short cut to defining a label string (you
could embed that in .R1/.R2 sections).

I have now found an ugly solution that works with -mom.
I use something like this near the top of my document:

.R1
# this extracts the last name of the first author and the publication date
label A.nD.y
database biblio.ref
.R2
\# Save Mom's version of ]- and ][
.rn ]- MOM-REFER-BEGIN
\# Provide my own versions: the brackets are inserted automatically so
you don't need
\# .[[ and .]] or [] in the flags field
\# \f(SC merely sets a small-caps font
\# [F contains the label as generated by refer
.ds ]- [\f(SC\\*([F\fP]\c
.rn ][ MOM-REFER-END
.ds ][

References can then be inserted without mom's .REF macros:
.[
whatever
.]

And to generate the bibliography I do:

\# restore mom's ]- and ][
.rn MOM-REFER-BEGIN ]-
.rn MOM-REFER-END ][
.
.BIBLIOGRAPHY
.BIBLIOGRAPHY_TYPE LIST
.R1
no-label-in-text
no-label-in-reference
sort A1Q1T1B1E1
reverse A1
bibliography biblio.ref
.R2
.BIBLIOGRAPHY OFF

So while for ordinary inline references I did the formatting with
custom macros, in the bibliography I let mom do it.
The entire database (biblio.ref) is inserted by refer, which is fine
as long as I do not have a real database (with lots of entries) but
one that contains only the publications I have ever referred to in the
main body of the text.

regards,
Robin

Re: [ovs-discuss] intermitting ARP problems on DP interface

[Robin Haberkorn]

Hi,

working at the same company, perhaps I can clarify this a bit.
Firstly, we are using openvswitch v1.2.2, the linux kernel
datapath implementation and the test-openflowd openflow
switch (we have good reasons not to use ovs-vswitchd).

Restarting the controller means we've restarted (after
SIGTERMinating) the test-openflowd user space daemon
previously attached to a datapath in order to check whether
our system recovers from test-openflowd crashes.
After the restart, the switch successfully reconnects to
our openflow controller but approx. every 10 seconds,
nothing received at the datapath's local port is properly
forwarded (to a physical switch port or our controller).
This situation persists for a few seconds until it seems
to recover and work properly again for about 10 seconds, etc.

btw. I guess the received packet on unknown port 65534 message
alludes to an openvswitch bug since 65534 is the openflow LOCAL
port while the source code states that an odp port should
be logged. LOCAL however is odp-port 0. So it appears that
somehow the two port types got mixed up.

cheers,
Robin Haberkorn

- Original Message -
 Hi,
 
 We have encountered a strange behavior. After restarting the
 controller process and even after removing and reinserting the
 datapath module, ARP packets are forwarded from dp0 to the real port
 intermittently.
 tcpdump confirms that the ARP request is seen on dp0, but not on the
 physical port (eth1).
 At the same time the following sequence on log messages appear:
 
 Oct 18 12:22:54|00344|netlink_socket|DBG|nl_sock_recv__ (Success):
 nl(len:24, type=30(ovs_packet), flags=0, seq=0,
 pid=0(0:0)),genl(cmd=1,version=1)
 Oct 18 12:22:54|00345|dpif|DBG|system@dp0: miss upcall:
 in_port(0),eth(src=00:23:20:fc:70:43,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=172.28.0.1,tip=172.28.0.19,op=1,sha=00:23:20:fc:70:43,tha=00:00:00:00:00:00)
 00:23:20:fc:70:43  ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length
 42: Request who-has 172.28.0.19 tell 172.28.0.1, length 28
 Oct 18 12:22:54|00346|ofproto_dpif|WARN|bridge dp0: received packet
 on unknown port 65534
 Oct 18 12:22:54|00347|netlink_socket|DBG|nl_sock_transact_multiple__
 (Success): nl(len:140, type=30(ovs_packet), flags=1[REQUEST],
 seq=4e9d5835, pid=75500397(2925:18)),genl(cmd=3,version=1)
 Oct 18 12:22:54|00348|netlink_socket|DBG|nl_sock_transact_multiple__
 (Success): nl(len:92, type=29(ovs_flow), flags=5[REQUEST][ACK],
 seq=4e9d5836, pid=75500397(2925:18)),genl(cmd=1,version=1)
 Oct 18 12:22:54|00349|netlink_socket|DBG|nl_sock_recv__ (Success):
 nl(len:36, type=2(error), flags=0, seq=4e9d5836,
 pid=75500397(2925:18)) error(0, in-reply-to(nl(len:92,
 type=29(ovs_flow), flags=5[REQUEST][ACK], seq=4e9d5836,
 pid=75500397(2925:18
 
 There clearly is something strange going on. How can the dp receive
 something on an unknown port?
 
 Any hints?
 
 Regards
 Andreas
 --
 --
 Dipl. Inform.
 Andreas Schultz
 
 email: a...@travelping.com
 phone: +49-391-819099-224
 mobil: +49-179-7654368
 
 -- managed broadband access --
 
 Travelping GmbH   phone:   +49-391-8190990
 Roentgenstr. 13   fax:   +49-391-819099299
 D-39108 Magdeburg email:   i...@travelping.com
 GERMANY   web:   http://www.travelping.com
 
 Company Registration: HRB21276 Handelsregistergericht Chemnitz
 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
 --
 
 ___
 discuss mailing list
 discuss@openvswitch.org
 http://openvswitch.org/mailman/listinfo/discuss
 
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: libev's child reaping breaks system() function

[Robin Haberkorn]

- Original Message -
 From: Marc Lehmann schm...@schmorp.de

 Since you can install your own sigchld handler already, this doesn't
 seem
 to be so helpful?
 
I admit, it wouldn't be that useful, but it would be cleaner to use
an ev_signal instead of an ev_async+custom signal handler.

  Also system() isn't broken by multithreading - it works fine as
  long as only one thread's executing system() at a time.
  It's the child reaping that breaks it.
 
 It works fine without multithreading, so how is it libev?
 
I also considered this - as I already mentioned. I didn't get any
feedback from the uClibc people though. But since libev's default
child-reaping side-conditions also break waitpid() calls in multithreaded
environments, I see the responsibility more on your side.

Let's summarize the problem *again*:
libev's internally reaps any child process (see childcb() in ev.c).
This results in child-reaping race conditions with any concurrent
waitpid() call, including system() calls that cannot mask out the
signals correctly.
If you don't need event-based child termination handling, you can
reset SIGCHLD signal handler (presumably to default since when
ignoring the signal, the kernel won't keep zombie-children).
But if you still want to use libev for child reaping you can't
simply use an ev_signal and do waitpid()s in its handler, e.g.
don't reap any child but only children that don't intersect with
children reaped concurrently to prevent race conditions.
The only solution I'm aware of is using a custom SIGCHLD signal
handler and activating an async watcher when the signal handler
gets invoked. This is like simulating an ev_signal.
Is this the way I'm supposed to go under these circumstances?

 So far, you have not explained how libev breaks system, btw. On a
 naive
 implementation, you'd simply get ECHILD, which is documented by POSIX
 for
 this case, so apparently libev doesn't break anything at all.
 
  *any* other waitpid() occurrence by resulting in race
  conditions. waitpid() is even defined as thread-safe.
 
 The (documented) behaviour of waitpid is not changed by libev though.
 
That's true, there are no segfaults. But imagine libev or some other
library would always ignore SIGCHLDs, maybe repeatedly to prevent
the user from fixing the handler. waitpid() wouldn't be able to
reap children anymore. This would be documented waitpid()
behaviour, too.
I would think that a library with such side-conditions, effectively
breaking a documented system call is poorly designed.

  Making the mechanism asynchronous/non-blocking, would
  require major code refactoring and make conceptually
  simple code dis-proportionally harder to read.
 
 Seems like an empty claim - can you back it up?

Yes. Usually you're using system() for programs that
aren't expected to run long enough to cause any trouble.
That's why it may well be used in libev watcher handlers.
Now if you replace these calls with some implementation that
forks and registers an ev_child (you're still interested in
the termination status!) you'll get your result in the watcher
handler. Since your code might depend on the status, you have
to continue in that handler. This complicates otherwise
simple code because it cannot be written sequentially
anymore.
Let's not talk about the problems you would have when
using that mechanism from a thread that hasn't got the
default loop (the only one supporting signal/child
watchers).

cheers,
Robin

-- 
-- 
-- managed broadband access --

Travelping GmbH   phone:   +49-391-8190990
Roentgenstr. 13   fax:   +49-391-819099299
D-39108 Magdeburg email:   i...@travelping.com
GERMANY   web:   http://www.travelping.com


Company Registration: Amtsgericht Stendal Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
--

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

Re: libev's child reaping breaks system() function

[Robin Haberkorn]

 
 multi-threading itself breaks a lot of stuff (fork for example) in
 subtle
 ways. this issue is not really something that libev can do something
 about.
 
libev can easily do something about it: make child reaping more
flexible by allowing SIGCHLD ev_signals.
Also system() isn't broken by multithreading - it works fine as
long as only one thread's executing system() at a time.
It's the child reaping that breaks it. It will also break
*any* other waitpid() occurrence by resulting in race
conditions. waitpid() is even defined as thread-safe.

 the solution is to not use system then, just as any other funciton
 that
 causes problems when threading.

ok, suppose I won't use system() anymore. The thing is if I
would rewrite it on my own, I would have to do it very
similar to the libc implementation. As a result, I would
experience the same kind of race condition.
Using an event-based child termination handling while keeping
the system()-like function synchronous/blocking would
introduce an unnecessary synchronization overhead
(like adding ev_childs to the default loop belonging to
another thread and using condition variables) as well
as other problems.
Making the mechanism asynchronous/non-blocking, would
require major code refactoring and make conceptually
simple code dis-proportionally harder to read.

  That doesn't seem to be pretty much straight-forward.
  IMHO, I could live without the ev_child watcher at all but
  I would be happy with a clean way to use ev_signal to process
  SIGCHLDs.
 
 Don't use system or multihreading - posix is harsh, and multithreading
 imposes rather draconic limitations on a program. not much that can be
 doen about it. it's a pain in the ass, but libev can only use what
 posix
 offers.

I don't see why this shouldn't be possible (and as I
pointed out, it is already using a custom signal handler and
async watcher).
Is there a design decision that says: either be content
with libev's default child reaping or don't use any event-based
child reaping approach at all?

cheers,
Robin
-- 
-- 
-- managed broadband access --

Travelping GmbH   phone:   +49-391-8190990
Roentgenstr. 13   fax:   +49-391-819099299
D-39108 Magdeburg email:   i...@travelping.com
GERMANY   web:   http://www.travelping.com


Company Registration: Amtsgericht Stendal Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
--

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

libev's child reaping breaks system() function

[Robin Haberkorn]

Hi!

I don't know if that has been brought up before (I couldn't
find anything). libev reaps all child processess synchronously
in the default event loop. This behaviour can result in child
reaping race conditions, generally if waitpid() and in
particular if system() (declared in stdlib.h) is also used in
the program.
In single-threaded programs, this shouldn't cause any problem
because of the synchronous reaping. Even if children would
be reaped asynchronously, system() would block (mask out)
SIGCHLD temporarily.
However in multi-threaded environments, system() cannot
mask out SIGCHLD for every thread. I'm currently investigating
whether this is ok or a bug in itself. At least it happens with
both uClibc and glibc which use a similar system()
implementation (which call sigprocmask() for masking out
SIGCHLD...).
Of course it would be possible to reset the signal handler
after default loop initialization, but what if you still want
to use events for child reaping purposes? It would still be
possible to reap only the children you're actually interested
in or synchronize the waitpid() and system() calls with a
mutex. Unfortunately it doesn't seem to be possible to
use an ev_signal for SIGCHLDs, maybe because libev uses an
ev_signal for child reaping internally!?
So the only way to not break the system() (and waitpid())
calls in a multi-threaded environment seems to be using
an async watcher. In pseudo-code:

ev_default_init(0);
ev_async_init(async, async_cb);
ev_async_start(EV_DEFAULT_UC_ async);
signal(SIGCHLD, chld_hnd);
...
void chld_hnd(int s) {
ev_async_send(EV_DEFAULT_UC_ async);
}
...
void async_cb(EV_P_ ev_async *w, int revents) {
// do whatever we would have done in an ev_signal handler
}

That doesn't seem to be pretty much straight-forward.
IMHO, I could live without the ev_child watcher at all but
I would be happy with a clean way to use ev_signal to process
SIGCHLDs.

cheers,
Robin

-- 
-- 
-- managed broadband access --

Travelping GmbH   phone:   +49-391-8190990
Roentgenstr. 13   fax:   +49-391-819099299
D-39108 Magdeburg email:   i...@travelping.com
GERMANY   web:   http://www.travelping.com


Company Registration: Amtsgericht Stendal Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
--

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

ev_default_destroy's behaviour

[Robin Haberkorn]

Hi!

from the information given in the manpage I would expect that 
ev_default_destroy() cleans up the default event loop in such a way it can be 
reinitialized and behaves as if it was never used (as long as there were no 
active signal/child watchers and you don't care about the watchers that were 
active before the call).
In other words, I would expect a small program like this one to return 
immediately:

int
main(int argc, char **argv)
{
ev_timer timer;

ev_timer_init(timer, timer_cb, 10., 0.);
ev_timer_start(EV_DEFAULT_ timer);

ev_default_destroy();

ev_loop(EV_DEFAULT_ 0);

return 0;
}

however it doesn't - it blocks indefinitely. Of course I can stop the watcher 
and everthing's fine. I just wanted to know whether ev_default_destroy() is 
supposed to work that way and if not exactly under which circumstances it can 
be useful.
I was tempted to use it once in a program where the default loop definitely 
makes sense (synchronizing signals without asyncs etc), at some point forks and 
has to clean up the default loop in the new process to allow some scripts to 
work with it (no execve either). I ended up stopping all watchers  resetting 
the still-messed-up signal handlers manually after invoking ev_default_fork().

cheers,
Robin Haberkorn

-- 
-- 
-- managed broadband access --

Travelping GmbH   phone:   +49-391-8190990
Roentgenstr. 13   fax:   +49-391-819099299
D-39108 Magdeburg email:   i...@travelping.com
GERMANY   web:   http://www.travelping.com


Company Registration: Amtsgericht Stendal Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
--


___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev