Re: [HelenOS-devel] How to display/interpret benchmark results?

[Vojtech Horky]

Hi, Jiri,

út 23. 1. 2024 v 13:48 odesílatel Jiri Svoboda  napsal:
> Currently hbench selects the number of cycles, takes 10 time measurements. It 
> then computes the average and standard deviation of the time taken. It then 
> computes and displays the rate from the average time and cycle count.
>
> I am really interested in the rate, not the time. What I am missing is a 
> number on the spread of the rate.
> What is the correct way of doing this?
> Is it correct to compute the rate from the average time? Or should we average 
> the rates and get SD from there?

I am not an expert but I have my $0.02 anyway.


First of all, why do we need to compute the rate at all? What is wrong
with displaying wall-clock time? I guess it is more natural for
multithreaded benchmarks where you want to take into account the
overall throughput across many CPUs but I am not sure if it applies
here?

Anyway, I guess the best would be to use harmonic mean when talking
about rates. And I have stumbled across this question [1] which may
apply to us as well?

[1] 
https://stats.stackexchange.com/questions/7471/can-the-standard-deviation-be-calculated-for-harmonic-mean


And now for the opinionated part :-).

I would humbly suggest against displaying only the average values. It
would be really great if there would an option to dump all the samples
to a file for later analysis (i.e., outside of HelenOS). When the
difference is in order of magnitude, displaying the average only is
probably fine. But for smaller differences one might want to use some
kind of statistical test (t-test is fine with mean and SD but
Mann-Whitney needs the individual samples if I remember correctly) or
compute confidence intervals (e.g. via bootstrap). And for these
knowing the individual samples is a must.

I really like how Renaissance benchmark suite does that: you can dump
all the data into JSON and it contains information about measurements
as well as about the environment. I am unable to find an online
example but this [2] Zenodo record contains raw JSON dumps too where
you can see several examples of the dumps (they are very JVM-oriented
but I like the general concept of storing environment information,
data format version and the actual measurements in one file).

[2] https://zenodo.org/records/4492935

As a matter of fact I think we should dump as much (raw) information
as we have. It happened to me many times already that I had to
re-measure something because I forgot to take down some information
about the environment. Be it precise kernel version, IP address or L3
cache size. In HelenOS we do not have that much information available
but my experience is that one should not throw away any information.


But because I am not actually implementing it it is very easy to come
up with ideas that mean work for someone else. I think using the right
type of mean is the only relevant part. Please, feel free to ignore the
rest :-)


Cheers,
- Vojtech

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 106th HelenOS project meeting

[Vojtech Horky]

Hello, Martin,

čt 14. 12. 2023 v 22:53 odesílatel Martin Decky  napsal:
> after a break of more than two years, I would like to announce the 106th
> (numbered) HelenOS project meeting that will take place on Saturday
> January 13th 2024 shortly after 2 p.m. local time somewhere in Prague,
> Czech Republic.
>
> Please let me know whether you plan to come so that I can make a
> reasonable reservation, no later than by Thursday January 11th 2024
> evening. Should you have any preferences, anti-preferences or
> constraints regarding the venue, please let me know as well.

Please, count me in. I have slight preference towards a place offering
a Czech cuisine.

Thank you and see you on Saturday,
- Vojta

>
>
> Best regards
>
> Martin Decky
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Coastline builds failing on ci.helenos.org

[Vojtech Horky]

Hello,

po 13. 11. 2023 v 15:57 odesílatel Jiří Zárevúcky
 napsal:
> On Mon, 13 Nov 2023 at 08:52, Vojtech Horky  wrote:
> > A lot of the ported software fails because it cannot resolve header
> > includes. It is probably related to the deduplication and introduction
> > of the  /common directory; it seems to me that some directories are
> > missing in export.sh?
> >
>
> Yes. Committed a fix for that, let's see if it works now.

Thanks for the quick fix. It looks much better now :-)

I expect one column would improve after merging of [1] and I hope to
have a look at the rest when I have some spare time.

[1] https://github.com/HelenOS/helenos/pull/228

Cheers,
- Vojtech

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Coastline builds failing on ci.helenos.org

[Vojtech Horky]

Hello,

ne 22. 10. 2023 v 21:37 odesílatel Jiří Zárevúcky
 napsal:
> On Sun, 22 Oct 2023 at 15:32, Jiri Svoboda  wrote:
> > I fixed export.sh to deal with thin archives and fixed conflict in GZX that 
> > was causing its coastline build to fail. I went to check on ci.helenos.org 
> > if it worked and now I see *all* coastline builds of all packages on 
> > ci.helenos.org failing in a strange way.
> > It fails while trying to build binutils. Any idea what's going on?
>
> I'm as stumped as you are.
> I tried running CI locally and it worked pretty ok.

I have finished the installation of the new CI machine and the latest
build looks like everything is setup correctly (well, almost).

A lot of the ported software fails because it cannot resolve header
includes. It is probably related to the deduplication and introduction
of the  /common directory; it seems to me that some directories are
missing in export.sh?

I have some fixes for running on new version of MSIM (the device is
now d4rkcpu, not dcpu and we need to run with -n to enable
non-deterministic behavior with keyboard). I will open a PR for this.

Cheers,
- Vojtech

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] HelenOS Camp 2024

[Vojtech Horky]

Hello, Jakub,

st 26. 7. 2023 v 11:09 odesílatel Jakub Jermář  napsal:
> Let me know if you'd like to attend and whether we should start
> organizing this.

I would like to attend but I will know my summer schedule probably
very late. I do not want to be a blocker on this, so please plan
without me.

But I would be happy if you can keep me in CC if the planning goes
off-list. Thanks!

Cheers,
- Vojtech

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Travis-ci.org going down

[Vojtech Horky]

Hi,

I think I managed to finish the migration (it needed a few extra
kicks). I just  triggered a rebuild so we will see :-)

Cheers,
- VH

út 15. 6. 2021 v 11:46 odesílatel Jiri Svoboda  napsal:
>
> Hi,
>
> It seems travis-ci.org is finally shutting down today. I was trying to 
> migrate to travis-ci.com a few days ago but didn't quite manage it, I'm not 
> quite sure what needs to be done. Anybody has an idea if that is a viable 
> option?
>
> Regards,
> Jiri
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Notes on last CI update

[Vojtech Horky]

ing it is to make changes when there's people who don't care
> > enough to review changes before they are merged, then wait months, and
> > then crawl out of woodwork complaining about how it's frustrating
> > *them* that massive changes they didn't give two shits about aren't
> > perfect right of the bat.
> >
> > > We cannot make exceptions to this rule, be it for desirability of a 
> > > featre, "momentum" of HelenOS camp or anything else.
> > >
> > >
> > > Regards,
> > >
> > > Jiri
> > >
> > >
> > > Jakub
> > >
> > > >
> > > > Cheers,
> > > > Jiri
> > > >
> > > >
> > > > -- Původní e-mail --
> > > > Od: Vojtech Horky 
> > > > Komu: HelenOS development mailing list 
> > > > Datum: 12. 11. 2019 23:35:58
> > > > Předmět: [HelenOS-devel] Notes on last CI update
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I have updated CI scripts on the CI server and new build just finished.
> > > >
> > > > TL;DR: Follows about 5 paragraphs of complaints and shed tears ;-).
> > > > Ended by brief summary of the last build.
> > > >
> > > > First of all, I understand that everyone is working on HelenOS in his
> > > > spare time but I do not think that should be an excuse for breaking
> > > > things and creating extra load on others. I acknowledge that I am
> > > > responsible for ci.helenos.org and that my lack of time caused that it
> > > > was in such bad shape recently. But at least some things could have
> > > > been prevented.
> > > >
> > > > Please, next time when there is such a big update (I mean things like
> > > > Meson etc.) it would be nice if someone would contact me in advance.
> > > > You know, just a short e-mail "hey, could you try this on CI machine
> > > > before we merge it into mainline so we have seamless transition?". And
> > > > yes, I am receiving e-mails from GitHub but automated notifications
> > > > simply got lower priority than normal e-mail.
> > > >
> > > > It would be also nice if changes to the build system would be
> > > > propagated to other repositories too. CI script was broken for about 2
> > > > months, the hotfix from 99d248b is not really complete. Not dwelling
> > > > on the fact that we needed two rounds of e-mails before the problem
> > > > was even acknowledged.
> > > >
> > > > @le-jzr: have you ever tried to run the CI script or you do just
> > > > search-and-replace when "fixing" it? I understand that it is not a
> > > > ten-liner any more but we do not have anything better at the moment.
> > > > Or do we?
> > > >
> > > > And this is really not the first time similar thing has happened.
> > > > Honestly, it just kills my motivation to work on HelenOS.
> > > >
> > > >
> > > > Regarding last build:
> > > >
> > > > HelenOS seems to be built okay, tests with bare images are more or
> > > > less fine too.
> > > >
> > > > Some harbours are failing as before, gzx, msim and sycek are broken
> > > > for all platforms.
> > > >
> > > > It seems that building extended images (e.g. HelenOS with binutils) is
> > > > broken as all tests fail with "command not found".
> > > >
> > > > As an improvement, it would be nice if ninja inside CI would not be
> > > > that smart about parallelism level. The jobs are already running in
> > > > parallel and running the inner build in parallel too only increases
> > > > the chances that the build would fail.
> > > >
> > > > Cheers,
> > > > - Vojta
> > > >
> > > > ___
> > > > HelenOS-devel mailing list
> > > > HelenOS-devel@lists.modry.cz
> > > > http://lists.modry.cz/listinfo/helenos-devel
> > > >
> > > >
> > > > ___
> > > > HelenOS-devel mailing list
> > > > HelenOS-devel@lists.modry.cz
> > > > http://lists.modry.cz/listinfo/helenos-devel
> > > >
> > >
> > > ___
> > > HelenOS-devel mailing list
> > > HelenOS-devel@lists.modry.cz
> > > http://lists.modry.cz/listinfo/helenos-devel
> > >
> > > ___
> > > HelenOS-devel mailing list
> > > HelenOS-devel@lists.modry.cz
> > > http://lists.modry.cz/listinfo/helenos-devel
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Notes on last CI update

[Vojtech Horky]

Hello.

st 13. 11. 2019 v 10:01 odesílatel Jakub Jermář  napsal:
> about it. The integration happened during a HelenOS camp and I basically
> urged JZv to push this because of the momentum. Yes, there was some
> confusion as to whether CI needs some changes. Also, it is not very easy
> to get new CI changes deployed, which exacerbated the problem.

Confusion? I doubt that the CI script was tried at all.

And the problem of deployment is that there were no changes to deploy ;-).


> Also, we are not a professional/commercial software house with paid
> developers and customers. We can afford to fix things later. And in
> general we do and have always done.

Merging incomplete implementations is different from breaking things
that used to work.

And generally I believe that the fact that we are not a commercial
software house means we have to be even more careful about this.
Because this basically transfers the load to someone else, costing him
his spare time.

- Vojta


>
> Jakub
>
> >
> > Cheers,
> > Jiri
> >
> >
> > -- Původní e-mail --
> > Od: Vojtech Horky 
> > Komu: HelenOS development mailing list 
> > Datum: 12. 11. 2019 23:35:58
> > Předmět: [HelenOS-devel] Notes on last CI update
> >
> >
> > Hello,
> >
> > I have updated CI scripts on the CI server and new build just finished.
> >
> > TL;DR: Follows about 5 paragraphs of complaints and shed tears ;-).
> > Ended by brief summary of the last build.
> >
> > First of all, I understand that everyone is working on HelenOS in his
> > spare time but I do not think that should be an excuse for breaking
> > things and creating extra load on others. I acknowledge that I am
> > responsible for ci.helenos.org and that my lack of time caused that it
> > was in such bad shape recently. But at least some things could have
> > been prevented.
> >
> > Please, next time when there is such a big update (I mean things like
> > Meson etc.) it would be nice if someone would contact me in advance.
> > You know, just a short e-mail "hey, could you try this on CI machine
> > before we merge it into mainline so we have seamless transition?". And
> > yes, I am receiving e-mails from GitHub but automated notifications
> > simply got lower priority than normal e-mail.
> >
> > It would be also nice if changes to the build system would be
> > propagated to other repositories too. CI script was broken for about 2
> > months, the hotfix from 99d248b is not really complete. Not dwelling
> > on the fact that we needed two rounds of e-mails before the problem
> > was even acknowledged.
> >
> > @le-jzr: have you ever tried to run the CI script or you do just
> > search-and-replace when "fixing" it? I understand that it is not a
> > ten-liner any more but we do not have anything better at the moment.
> > Or do we?
> >
> > And this is really not the first time similar thing has happened.
> > Honestly, it just kills my motivation to work on HelenOS.
> >
> >
> > Regarding last build:
> >
> > HelenOS seems to be built okay, tests with bare images are more or
> > less fine too.
> >
> > Some harbours are failing as before, gzx, msim and sycek are broken
> > for all platforms.
> >
> > It seems that building extended images (e.g. HelenOS with binutils) is
> > broken as all tests fail with "command not found".
> >
> > As an improvement, it would be nice if ninja inside CI would not be
> > that smart about parallelism level. The jobs are already running in
> > parallel and running the inner build in parallel too only increases
> > the chances that the build would fail.
> >
> > Cheers,
> > - Vojta
> >
> > ___
> > HelenOS-devel mailing list
> > HelenOS-devel@lists.modry.cz
> > http://lists.modry.cz/listinfo/helenos-devel
> >
> >
> > ___
> > HelenOS-devel mailing list
> > HelenOS-devel@lists.modry.cz
> > http://lists.modry.cz/listinfo/helenos-devel
> >
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] Notes on last CI update

[Vojtech Horky]

Hello,

I have updated CI scripts on the CI server and new build just finished.

TL;DR: Follows about 5 paragraphs of complaints and shed tears ;-).
Ended by brief summary of the last build.

First of all, I understand that everyone is working on HelenOS in his
spare time but I do not think that should be an excuse for breaking
things and creating extra load on others. I acknowledge that I am
responsible for ci.helenos.org and that my lack of time caused that it
was in such bad shape recently. But at least some things could have
been prevented.

Please, next time when there is such a big update (I mean things like
Meson etc.) it would be nice if someone would contact me in advance.
You know, just a short e-mail "hey, could you try this on CI machine
before we merge it into mainline so we have seamless transition?". And
yes, I am receiving e-mails from GitHub but automated notifications
simply got lower priority than normal e-mail.

It would be also nice if changes to the build system would be
propagated to other repositories too. CI script was broken for about 2
months, the hotfix from 99d248b is not really complete. Not dwelling
on the fact that we needed two rounds of e-mails before the problem
was even acknowledged.

@le-jzr: have you ever tried to run the CI script or you do just
search-and-replace when "fixing" it? I understand that it is not a
ten-liner any more but we do not have anything better at the moment.
Or do we?

And this is really not the first time similar thing has happened.
Honestly, it just kills my motivation to work on HelenOS.


Regarding last build:

HelenOS seems to be built okay, tests with bare images are more or
less fine too.

Some harbours are failing as before, gzx, msim and sycek are broken
for all platforms.

It seems that building extended images (e.g. HelenOS with binutils) is
broken as all tests fail with "command not found".

As an improvement, it would be nice if ninja inside CI would not be
that smart about parallelism level. The jobs are already running in
parallel and running the inner build in parallel too only increases
the chances that the build would fail.

Cheers,
- Vojta

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 101st HelenOS project meeting

[Vojtech Horky]

Hello, Jakub.

ne 7. 4. 2019 v 13:48 odesílatel Jakub Jermář  napsal:
> we should have our 101st HelenOS project meeting next week. I am
> wondering if people would rather like to meet on a weekend rather than
> on Thursday evening as some commute from a far.

I will not make it (neither this or next week). I do not have any
updates anyway.

Cheers,
- Vojtech


>
> Jakub
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] I need some tips with coding for the HelenOS

[Vojtech Horky]

Hello, Dmitrij,

I think your assumptions about HelenOS are too optimistic ;-)

st 19. 12. 2018 v 11:50 odesílatel Dmitrij V  napsal:
> To write HW GPU drivers by scratch is titanic work ! - easier to stay
> in linux space without attempts to look to other sides(OS). I had
> thinked to adapt libdrm for HelenOS (nativelly written for linux).

To do that, HelenOS would have to support the Linux API that is needed
(e.g. various ioctls you mentioned). But we support only POSIX API for
end-user applications (and only a small subset).

Furthermore, the HelenOS device drivers would have to provide the
functionality that is (in case of libdrm) provided by Linux (i.e. the
called side of ioctl). And in this sense, HelenOS has only rudimentary
support for graphical output.

> I had looked for small and fast OS, with supporting modern compiller
> (GCC is preferred) & c++ standarts for programming for that, for port
> to there a light gui library for writting modern looked gui etc...

You are in the right place and it would certainly be nice to have some
3rd party GUI library ported :-).

But beware that it would be a lot of work. For example, GTK supports
various backends (Windows, X11 etc.) and the work of porting the
library means adding a whole new backend.

Hope this helps clarify some confusion :-)

Cheers,
- Vojtech


>
> --
> the best regards
>
> 2018-12-19 14:30 GMT+05:00, Jiri Svoboda :
> >
> > Hi,
> >
> >
> >
> >
> > if you are serious about contributing, I suggest reading the code carefully
> >
> > and starting with something really simple. If this is supposed to be some
> > kind of a plan to introduce HW acceleration support to HelenOS, then it's
> > obvious you have no idea what you are talking about. You've just picked up
> > some random Linux packages related to graphics and suggested they should be
> >
> > ported. Have you even an idea what those packages are/do? How would they
> > fit
> > in HelenOS graphics stack?
> >
> >
> >
> >
> >
> > -Jiri
> >
> > -- Původní e-mail --
> > Od: Dmitrij V 
> > Komu: HelenOS development mailing list 
> > Datum: 19. 12. 2018 6:20:46
> > Předmět: Re: [HelenOS-devel] I need some tips with coding for the HelenOS
> > "Hello !
> >
> > Sorry for my delayed post...
> >
> > I had some time for researching the "Helen OS & GPU drivers",
> > there are all done already:
> >
> > 1) libdrm (needs to port)
> > (no deep digging, something like requerements for posix ioctl ...)
> >
> > 2) svgalib (needs to port, native is linux) (it has support opengl
> > interface)
> >
> > -
> > regards
> >
> > ___
> > HelenOS-devel mailing list
> > HelenOS-devel@lists.modry.cz
> > http://lists.modry.cz/listinfo/helenos-devel
> > "
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Switching away from Trac?

[Vojtech Horky]

čt 29. 11. 2018 v 0:01 odesílatel Jakub Jermář  napsal:
> On 11/28/18 11:54 PM, Vojtech Horky wrote:
> > are we preparing to  abandon our Trac instance? Because I received
> > 100+ e-mails from prehistoric Trac issues generated by GitHub. It
> > seemed to me as someone was trying to do mass export-import?
>
> It was me. I was experimenting a little, but my conversion script was
> stopped by GitHub abuse detection mechanism (despite measures to
> throttle down the request rate) after some 50 tickets were converted.
> Sorry for all the e-mail notifications.

No problem :-)

> After this experiment, I don't think it is realistic to import the Trac
> tickets into GitHub. But we can keep the issues enabled and use them in
> parallel and later as a replacement to Trac.

Any particular reason why do you want to replace Trac? I thought that
we want eventually to have master back on helenos.org and have GH as a
backup.

- Vojta

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] Switching away from Trac?

[Vojtech Horky]

Hello,

are we preparing to  abandon our Trac instance? Because I received
100+ e-mails from prehistoric Trac issues generated by GitHub. It
seemed to me as someone was trying to do mass export-import?

- Vojta

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] The 100th HelenOS project meeting

[Vojtech Horky]

Hello,

December 20 is fine with me, 13th as well.

Cheers,
- Vojta

so 24. 11. 2018 v 21:00 odesílatel Jakub Jermář  napsal:
>
> Hi,
>
> we are going to have our 100th HelenOS project meeting before Christmas.
> Please let me know if December 20 is fine or if some other date works
> better for you.
>
> Thanks,
> Jakub
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] Harbours built but fails to run?

[Vojtech Horky]

Hello,

it seems that some recent changes caused that harbours are being built
(well, most of them) but once they are executed, they dereference a
null pointer.

Logs are available in build 180 [1] and it is possible to download an
ISO image with GCC to test [2]. I tried in QEMU and even 'gcc
--version' did not work.

[1] http://ci.helenos.org/build-180/
[2] http://ci.helenos.org/build-180/amd64/helenos-amd64-with-gcc.iso

Because build 179 was okay, the issue is probably caused by changes on
May 25. I suspect the "Don't use custom ldscripts in uspace. (#38)"
(BTW, the period should not be there ;-)) [3] as that was the only
system-wide change.

[3] 
https://github.com/HelenOS/helenos/commit/a05ec6671002c451fceb01aa0ab3f71f004efb6d

Would someone, please, re-test that this is reproducible and is not a
CI-only problem.

Thanks,
- Vojta

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 98th HelenOS project meeting

[Vojtech Horky]

Hello.

2018-05-04 16:25 GMT+02:00 Jakub Jermář :
> The 98th HelenOS project meeting will take place on Thursday of May
> 11, shortly after 18:00 somewhere in Prague, Czech Republic. Please let

Just wondering, is it May 10 or Friday?

Anyway, I am planning to come (either day) and I have no preference
for the venue.

Cheers,
- Vojtech

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Reopening the discussion about #pragma once

[Vojtech Horky]

Hello.

2018-01-15 20:56 GMT+01:00 Jiří Zárevúcky :
>> - It's not standard.
>>
>> True, but meaningless. We use plenty of nonstandard extensions. It's
>> literally impossible to implement libc without using some.
>>
>> - Some archaic/toy compiler may not support it.
>>
>> Also true, but as JJ said, such a compiler wouldn't build HelenOS
>> anyway. #pragma once is supported by any half-serious C compiler (see
>> https://en.wikipedia.org/wiki/Pragma_once).

I think we should distinguish whether we are talking about the public
headers or the implementation itself. While it is true that a toy
compiler will not compile the whole HelenOS, such toy compiler can
still be used to compile against HelenOS headers. Not a common case
but due to simplicity of our library not a completely impossible one
either.

And I would say that especially for system (libc) headers we should be
as conservative as possible.

By the way, some libraries actually expect that headers are guarded
[1] and we had patches for that in Coastline [2] as we are using
uncommon naming (and yes, I think that it is wrong but that is not the
point).

[1] https://gmplib.org/repo/gmp-5.1/file/c0a9c060cb8a/gmp-h.in#l247
[2] https://github.com/HelenOS/harbours/blob/f089b58cd/libgmp/HARBOUR#L44

Just my $.02.

Cheers,
- Vojtech


>>
>> - `#pragma once` is in trouble if the same header is accessed via
>> multiple paths.
>>
>> Not an issue for us. Multipath headers are a bug, not a feature.
>>
>> -- jzr
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] FYI: Travis CI per-commit builds enabled

[Vojtech Horky]

Hello,
I just enabled Travis CI [1] builds of HelenOS on GitHub. Travis
should build HelenOS for all architectures on every commit an also on
pull requests.

Our CI nightly builds are remaining unchanged as Travis does not offer
way to provide downloadable artifacts.

I am still not sure how (and to whom) Travis sends e-mail when build
happens/fails. Please, let me know if you start receiving too many
e-mails and I will try to tune the configuration.

Cheers,
- Vojtech

[1] https://travis-ci.org/HelenOS/helenos

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] HelenOS Camp 2018 Early Planning

[Vojtech Horky]

Hello, Jakub.

2018-01-03 20:54 GMT+01:00 Jakub Jermář :
> I suggest the camp takes the same form as in 2017 (i.e. a kids camp) and
> takes place in Krusne hory in the week of August 25 to September 1.
Count us (preliminary) in, too.

Cheers,
- Vojta

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Configuring routes & forwarding

[Vojtech Horky]

Hello.

2017-12-18 19:40 GMT+01:00 Jiri Svoboda :
> - Currently HelenOS does not forward received datagrams and it's not
> possible to enable it using a configuration option. It should be rather easy
> to enable forwarding and just a little bit more work to make it
> configurable.

There is also the work done by Jan Buchar who added a packet-filter
[1] to HelenOS some time ago. It might be worth checking his code
whether some portions cannot be cherry-picked (clean merge is out of
question as it is 2 years old). The thesis might be a good starting
point [2].

Cheers,
- Vojtech

[1] https://code.launchpad.net/~teyras/helenos-pf/trunk
[2] http://www.helenos.org/doc/theses/jb-thesis.pdf

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] musl as replacement for libposix

[Vojtech Horky]

Hello, Jiri,

please, see my comments in-line.


Dne 5.12.2017 v 20:50 Jiri Svoboda napsal(a):
This way there is no problem with combining "native" code and code using 
libposix. Let's say, theoretically, that libjpeg needs some UNIX symbols 
that are not in pure C standard library. You'd still might want to use 
libjpeg in some native HelenOS code and it's FILE would have to be 
interoperatble with HelenOS FILE.
Right. I should have stated that I was really aiming for standalone 
applications and that I do not want to remove libposix. libposix as 
"native" library can coexist with the emulation layer.


Hopefully we can eventually bring libposix on par with musl but that is 
not something that would happen soon, I think.



The solution you are proposing promotes the status quo to a stated goal 
and cements it as the desired end state. Effectively you create an 
emulation layer on top of HelenOS that is completely isolated and cannot 
inter-operate with native HelenOS code. Even worse, you are introducing  
an extra implementation of ISO C standard library to the system. So 
there will be two: one for native applications (our own, incomplete) and 
one for the libposix environment (complete). Also means we are giving up 
providing a complete C implementation for native HelenOS code? Also, the 
goal of XCW environment is to provide standard C + HelenOS to 
multiplatform applications. How are you going to do that if you give up 
providing a proper C library to base HelenOS? Please don't tell me we 
don't have the resources to write and maintain our own implementation of 
C standard library, that's just not true.
[rant] Unfortunately the current state of standardworthiness of our libc 
and libposix tells the opposite. Moreover, it seems to me that no one is 
actually testing whether our ported software still works. For example, 
GCC is no longer able to build things. I have not yet tried to bisect 
when that started but I suspect that it is because the current duo 
libc/libposix is rather fragile. [end-of-rant]


As stated above, libposix can freely coexist but using musl still seems 
to me as an easier way to port applications to HelenOS. Furthermore I do 
not think that it harms the system if there are multiple C libraries. 
The applications can still communicate with each other, share files etc. 
and it only increases diversity.



I understand the want to provide the most complete functionality to 
ported applications. But, if I use the analogy of porting GNU 
applications to Windows, we want a MinGW (makes GNU software compile as 
native windows applications), not Cygwin (an enclosed emulation enclave 
on top of Windows).
Why (I mean the question seriously)? What is wrong with Cygwin from user 
perspective? It may not be the cleanest solution but it works and from 
my experience (several years ago, though) it worked very well...



Emulating Linux syscalls, seriously? If anything, adding a proper 
HelenOS port to an existing C library would be more meaningful.
Yes, seriously. It is actually a pretty clean cut. Well-defined and 
stable interface, generally follows POSIX standard and there are 
implementations on both sides of the layer to check the actual behaviour.


Anyway, do you know of any C library that could be used for porting to 
HelenOS in the way you propose? Because the ones I have seen targets one 
OS (kernel) only and adding a new "backend" would require non-trivial 
changes.




 > Some required headers are
 > expected to define hundreds of macros describing the system. Writing
 > such headers from scratch is difficult because they are often
 > Linux-specific and there is not much of a documentation anyway. And
 > taking these headers from existing libraries (e.g. glibc) introduces a
 > maintenance problem (and licensing might be an issue too).
This is confusing. I think the question here is what exactly are we 
trying to emulate with libposix. Glibc? A Linux libc? Why? Why not the 
FreeBSD libc? Actually I thought we were aiming for the C library as 
defined by the UNIX standard!


Software that we are trying to port to HelenOS is inherently portable 
and runs on multiple Unix-like platforms. Surely it does not absolutely 
depend on some Linux specific headers (it can run on FreeBSD, MINIX, 
AIX, Solaris ...) Something's amiss...
I wish I could agree. But why all the software we have ported so far 
uses complex configure scripts to actually detect what the system 
provides? Because despite a common standard there are differences.


And to achieve the compatibility we either need to mimic an existing 
library (contrary to common sense) or use an existing one. I believe it 
was libisl where they were testing for guard macros of stdio.h (i.e. 
#ifdef _stdio_h_) to control inclusion of different headers. Awful but 
common.



I hope the answers helped to clarify the intent and the motivation.

Cheers,
- Vojta





Cheers,
Jiri


--

Re: [HelenOS-devel] musl as replacement for libposix

[Vojtech Horky]

Hello, Jiri.

2017-12-05 13:20 GMT+01:00 Jiri Svoboda <jirik.svob...@seznam.cz>:
> I have some serious concerns regarding your proposed approach. Either I can
> give you feedback at the December meeting, or I can try to write it down.
> But you'd need to give me some time to write my thoughts down..
I plan to attend the meeting so we can discuss it there. But if you
would find some time to write it down it would probably help steer the
discussion.

Cheers,
- Vojta


>
> Regards.
> Jiri
> -- Původní e-mail ------
> Od: Vojtech Horky <vojtech.ho...@gmail.com>
> Komu: HelenOS development mailing list <helenos-devel@lists.modry.cz>
> Datum: 4. 12. 2017 20:27:07
> Předmět: [HelenOS-devel] musl as replacement for libposix
>
> Hello all,
>
> this is a report of a work I started on HelenOS camp regarding changes
> to libposix and the way how we build other applications.
>
>
> TL;DR version is: as an alternative, it is possible to use musl libc
> as the base library for ported software and build coastline packages
> with it. Internally, the actual (Linux) syscalls in musl are replaced
> with HelenOS handler that translates them to native HelenOS API. It
> seems to work (at least as a proof of concept) on ia32.
>
>
> Longer version follows. I am sorry for the length but I wanted to put
> all the information together so we can discuss whether we want to use
> this in HelenOS mainline. I have partially explained this already in
> my blog post [blog], I repeat it here again for completeness.
>
>
> I will start with a brief overview of issues we are facing with
> libposix. Historically libposix directly included files from libc to
> make them accessible to ported software. Some tweaks - usually to
> prevent clashes between names in libposix and libc - were done with
> special macros and various #ifdef tricks. That worked well except some
> packages actually defined macros to wrap standard functions with their
> replacements (and that broke when the identifier was already a macro).
> So we switched to renaming the symbols at object level and keeping
> libc and libposix headers as separated as possible (the changes in
> last weeks separating headers even more helped a lot too).
>
> That works pretty well yet our (libposix) headers are still somewhat
> different from glibc headers (a.k.a. "the libc" on GNU/Linux today)
> and configure scripts do not detect some functions correctly. That is,
> by the way, the reason why we define some "have-xy-header" macros in
> several harbour files.
>
> We are adding functions to libposix on demand: when new application is
> ported to HelenOS and some functionality is missing, we add it to
> libposix. That can have some adverse effects on its own as it may
> break existing applications (e.g. configure detected that some
> functions are missing and bypassed their usage, now they are there and
> the build process may crash because it expects to find other functions
> too).
>
> But the biggest issue is that we are now past the simple cases and we
> are adding a non-trivial definitions there that are difficult to
> maintain. Porting QEMU highlighted this. Some required headers are
> expected to define hundreds of macros describing the system. Writing
> such headers from scratch is difficult because they are often
> Linux-specific and there is not much of a documentation anyway. And
> taking these headers from existing libraries (e.g. glibc) introduces a
> maintenance problem (and licensing might be an issue too).
>
> So maybe it is time to look for another solution. And that is to find
> a suitable libc that could be tweaked to become the new POSIX
> emulation layer. The reasoning is that this existing libc would take
> care of proper definitions, would provide OS-agnostic functionality
> (e.g. sprintf) and we would only provide the binding that is HelenOS
> specific, such as file system operations.
>
> Ideally there should be a well-defined level where library does things
> on its own and where services from the OS are needed. Looking at
> existing libcs for Linux, this separation layer is at the level of
> system calls. Therefore if HelenOS would be able to emulate Linux
> system calls, any C library should work.
>
>
> And now about the actual implementation.
>
> I decided to use musl libc [musl] as the potential replacement of
> libposix. The reasons were that it is (1) actively maintained, (2) has
> MIT license and (3) is reasonably small yet reasonably complete
> [comparison]. The overall idea is that syscalls in musl would be
> replaced by a normal function call that would emulate them and mimic
> that the application is running on GNU/Linux.
>
> Since syscalls in musl 

Re: [HelenOS-devel] The December meeting

[Vojtech Horky]

> 2017-12-04 19:35 GMT+01:00 Jakub Jermář :
>> how many people would be able to make it to the December meeting in
>> person? Probably on Dec 16 or 17?
> 16th or 17th would be okay with me if not in the evening. But I cannot
> tell for sure now (will know the week before).
Dec 14th/15th is also okay with me.

- Vojta

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] musl as replacement for libposix

[Vojtech Horky]

Hello all,

this is a report of a work I started on HelenOS camp regarding changes
to libposix and the way how we build other applications.


TL;DR version is: as an alternative, it is possible to use musl libc
as the base library for ported software and build coastline packages
with it. Internally, the actual (Linux) syscalls in musl are replaced
with HelenOS handler that translates them to native HelenOS API. It
seems to work (at least as a proof of concept) on ia32.


Longer version follows. I am sorry for the length but I wanted to put
all the information together so we can discuss whether we want to use
this in HelenOS mainline. I have partially explained this already in
my blog post [blog], I repeat it here again for completeness.


I will start with a brief overview of issues we are facing with
libposix. Historically libposix directly included files from libc to
make them accessible to ported software. Some tweaks - usually to
prevent clashes between names in libposix and libc - were done with
special macros and various #ifdef tricks. That worked well except some
packages actually defined macros to wrap standard functions with their
replacements (and that broke when the identifier was already a macro).
So we switched to renaming the symbols at object level and keeping
libc and libposix headers as separated as possible (the changes in
last weeks separating headers even more helped a lot too).

That works pretty well yet our (libposix) headers are still somewhat
different from glibc headers (a.k.a. "the libc" on GNU/Linux today)
and configure scripts do not detect some functions correctly. That is,
by the way, the reason why we define some "have-xy-header" macros in
several harbour files.

We are adding functions to libposix on demand: when new application is
ported to HelenOS and some functionality is missing, we add it to
libposix. That can have some adverse effects on its own as it may
break existing applications (e.g. configure detected that some
functions are missing and bypassed their usage, now they are there and
the build process may crash because it expects to find other functions
too).

But the biggest issue is that we are now past the simple cases and we
are adding a non-trivial definitions there that are difficult to
maintain. Porting QEMU highlighted this. Some required headers are
expected to define hundreds of macros describing the system. Writing
such headers from scratch is difficult because they are often
Linux-specific and there is not much of a documentation anyway. And
taking these headers from existing libraries (e.g. glibc) introduces a
maintenance problem (and licensing might be an issue too).

So maybe it is time to look for another solution. And that is to find
a suitable libc that could be tweaked to become the new POSIX
emulation layer. The reasoning is that this existing libc would take
care of proper definitions, would provide OS-agnostic functionality
(e.g. sprintf) and we would only provide the binding that is HelenOS
specific, such as file system operations.

Ideally there should be a well-defined level where library does things
on its own and where services from the OS are needed. Looking at
existing libcs for Linux, this separation layer is at the level of
system calls. Therefore if HelenOS would be able to emulate Linux
system calls, any C library should work.


And now about the actual implementation.

I decided to use musl libc [musl] as the potential replacement of
libposix. The reasons were that it is (1) actively maintained, (2) has
MIT license and (3) is reasonably small yet reasonably complete
[comparison]. The overall idea is that syscalls in musl would be
replaced by a normal function call that would emulate them and mimic
that the application is running on GNU/Linux.

Since syscalls in musl are defined through a macro it is easy to
redefine it to call a central dispatcher of the emulation layer. The
actual emulation is implemented in libinux and currently supports (at
least partially) about 15 system calls. The important thing is that
libinux basically exports only two symbols - one for initialization
and one for the syscall handler. Everything else is separated (musl vs
libinux and HelenOS libc) and thus there shall not be any naming
clashes at all (it prefixes HelenOS libc functions as libposix does
but no shared headers are present).

Ported software is then compiled against musl headers and linked with
musl and libinux (together with our libc). That works very well and
for packages I tested so far I was able to remove all the hacks and
basically reduce number of patches to zero.


This new approach has some advantages and several disadvantages too.
The biggest advantage is that we compile the ported applications
against a full-fledged libc that is known to work and that greatly
simplifies the compilation process. We also reduce the amount of code
in HelenOS as we do not need to care about headers but only about
implementation of a few syscalls. There 

Re: [HelenOS-devel] The December meeting

[Vojtech Horky]

Hello, Jakub.

2017-12-04 19:35 GMT+01:00 Jakub Jermář :
> how many people would be able to make it to the December meeting in
> person? Probably on Dec 16 or 17?
16th or 17th would be okay with me if not in the evening. But I cannot
tell for sure now (will know the week before).

Cheers,
- Vojta

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] What is wrong with restrict parameters?

[Vojtech Horky]

Hello Jiri,

I have noticed the following commit [1] where the restrict keyword was
replaced with __restrict__ in multiple headers. I was wondering what
is the reason for replacing C99 standard keyword with a proprietary
extension (though implemented both by GCC and clang)? I assume they
are equivalent, right?

Thanks,
- Vojtech


[1] 
https://github.com/HelenOS/helenos/commit/0dd477996e38407057517d8fe2b97d416cd4e667

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Everyone please move to the git repository

[Vojtech Horky]

Hello,

I have also converted coastline and ci repositories, both are now on GitHub
too.

Updates to the CI script to use Git are on the way.

- Vojta


2017-11-12 21:01 GMT+01:00 Jakub Jermář :

> Hi all,
>
> from now on please use:
>
>   https://github.com/HelenOS/helenos
>
> as the new mainline repository.
>
> Even though the new repository contains a conversion of the old bzr and
> svn repositories, the old bzr repository should stay around in read-only
> mode at its current location.
>
> We also plan to maintain a clone of this on helenos.org later.
>
> Jakub
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Hangout/meeting this week or the next

[Vojtech Horky]

Hello,

I am not able to attend (both hangup and in person) neither this or next
week. Hopefully next time.

Cheers,
- Vojta


2017-09-12 13:32 GMT+02:00 Jakub Jermář :

> Hi,
>
> my calendar tells me there should be our monthly hangup/meeting this
> Thursday. The question on the table: is next week better than this week?
> Another question is: shall we meet in person this time?
>
> Jakub
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Cannot push to bzr://bzr.helenos.org/ci/

[Vojtech Horky]

2017-08-03 10:43 GMT+02:00 Vojtech Horky <vojtech.ho...@gmail.com>:

> I was trying to push some updates to the CI repository and I got back the
> following error:
>

So I tried again and it works now.

I have no idea why the break-lock worked now and not in the morning as it
seems that the lock was held since May :-(.

Sorry about the spam.

Cheers,
- Vojta




>
> Using saved push location: bzr+http://ho...@bzr.helenos.org/ci/
> HTTP ho...@bzr.helenos.org, Realm: 'HelenOS Bazaar repository' password:
> bzr: ERROR: Could not acquire lock "(remote lock)": bzr+
> http://ho...@bzr.helenos.org/
>
> Can someone with root access to the server (probably Martin only?) remove
> the lock, please? Thanks!
>
> Btw, I was pushing to mainline and coastline before that (I finally
> managed to commit/push bunch of related changes I had ready for some time)
> and that went okay.
>
> Cheers,
> - Vojta
>
>
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 96th HelenOS project meeting

[Vojtech Horky]

Hello.

2017-06-06 13:22 GMT+02:00 Martin Decky :

> No problem with that.
>>
>
> Great. So please count me in for June 15th.
>

Okay, please count me in for June 15th too.

Cheers,
- Vojta



>
>
> M.D.
>
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Nightly builds

[Vojtech Horky]

Hello, Jakub.

2017-05-04 18:10 GMT+02:00 Jakub Jermář <ja...@jermar.eu>:

> Hi Vojta,
>
> On 05/04/2017 08:41 AM, Vojtech Horky wrote:
>
>> I have updated the scripts at ci.helenos.org <http://ci.helenos.org>
>> with the new Pythonic version. We now offer downloadable images of HelenOS
>> for all architectures there.
>>
>> The page also provides
>> - tarballs with Coastline packages,
>> - logs from the compilation,
>> - results of automated tests,
>> - and special images (e.g. ISO for ia32 with GCC).
>>
>> The rebuild is done daily but only when new revision was pushed either to
>> mainline or coastline.
>>
>
> This is a very good news!
>
> - overview matrix (except for Python, it looks healthy now),
>>
>
> Python is broken after the merge of the VFS improvements. When I was
> looking at it, it wasn't clear to me why it was failing as it was. If
> anyone knows any better, I'd be very grateful.
>
I remember we discussed that on IRC. The reason seemed obvious (undefined
functions when linking) but I have no idea why it fails for these functions
now as they have not changed at all from Python's point of view.


Also pcc seems to be broken more than necessary.
>
AFAIK PCC is broken for quite a long time but we have (more or less
working) GCC and thus no one cares that much about PCC.



> Perhaps the ci should have a means to disable CI builds for certain
> architectures. Or the harbours should not attempt to build when it does not
> make sense.
>
Currently, it works the other way around - you can select to build for only
specific architectures/harbours.

But when building does not make sense? I think we should aim for having the
whole matrix in the green. And the purpose of the CI build is to know the
overall status.

Cheers,
- Vojta
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] Nightly builds

[Vojtech Horky]

Hello all,
I have updated the scripts at ci.helenos.org with the new Pythonic version.
We now offer downloadable images of HelenOS for all architectures there.

The page also provides
- tarballs with Coastline packages,
- logs from the compilation,
- overview matrix (except for Python, it looks healthy now),
- results of automated tests,
- and special images (e.g. ISO for ia32 with GCC).

The rebuild is done daily but only when new revision was pushed either to
mainline or coastline.

Cheers,
- Vojtech
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 95th HelenOS project meeting

[Vojtech Horky]

Hello, Jakub.

2017-03-30 16:07 GMT+02:00 Jakub Jermář :

> The 95th HelenOS project meeting will take place on Thursday of April
> 13, shortly after 19:00 somewhere in Prague, Czech Republic. Please let
> me know whether you plan to come so that I can make a reasonable
> reservation, no later than by morning of April 12. Also, do let me know
>
Please, count me in.

Cheers,
- Vojtech



> whether you have any preferences for the venue of the meeting.
>
> Jakub
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Final proposal draft assessment request

[Vojtech Horky]

Hello, Supragya.


2017-04-02 18:51 GMT+02:00 Supragya Raj :

> Hi HelenOS devel team,
>
> Thank you for supporting and giving feedback on proposal revisions (GSoC
> application). This is probably the final request asking to provide feedback
> on the final draft. Almost all of the asked changes have been incorporated.
> The proposal is uploaded as a GSoC final proposal for "just in case".
>
> Can u suggest any other feedback? Are the explanations apt and adequate?
> Or do you find any other issue with the proposal?
>
Just going through it.


P.S.: Vojtech, you asked me to provide code for elastic horse regression
> example in the script. Turns out most of it is sequential in nature and
> would require nothing more than adding < > around the commands to prove in
> becoming a HLang script. Should I still add it as an example in proposal?
> Also, I have removed the idea of explicit data types. Kindly verify the same
>
Probably I have not explained my idea clearly. Right now, this FS check you
talk about is done manually, e.g. a person types the individual commands
and verifies that the apps started, no error was printed, etc. It would be
very useful to automate this.

Thus, how would the automation look like in HLang? The first command would
certainly be
< mkfile --size 2m /tmp/img >;
But, how would you check (from within the script) that the command
succeeded? Something like Bash equivalent to [ $? -eq 0 ]? And so on.
Eventually, I would expect that the script would either print "Test passed"
or "Test failed".

I just though that you might use it to illustrate various concepts in HLang.

Cheers,
- Vojtech



>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
>
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] terminal

[Vojtech Horky]

Hello.

2017-03-21 6:39 GMT+01:00 punk joker :

> For newsletter subscribe, answers do not come. Try to use a different
> email address.
>
Would you provide a bit more information here, please?



> Now in the case. To begin, I decided to just change the buffer to the new
> window size, if necessary, ejecting the superfluous data. In this approach,
> the increase in the working window. But decreasing when the window size
> becomes less than the current position, the program crashes. Most likely
> there is an attempt to withdraw the data or to set the cursor beyond the
> boundaries of the buffer. But unfortunately, I can't find the problem.
> Edited these files:
> /home/joker/HelenOS/mainline/uspace/lib/c/generic/io/chargrid.c
> /home/joker/HelenOS/mainline/uspace/lib/gui/terminal.c
> Modified files attached to the letter.
>
Thanks for the files. I have looked at your modifications and I have a few
comments/questions.

First of all, it is much better if you send your changes as a patch that
can be applied rather than modified files only. For example, I assume you
also changed uspace/app/vterm/vterm.c adding the WINDOW_RESIZEABLE flag.

Now, to the changes. The chargrid_destroy is a little bit more complicated
than your solution. If you look in chargrid_create, the memory might also
come from as_area_create ...

Your patch discards cursor position. When the window is being enlarged I
would expect that the position could be kept the same. Would it be possible
to fix that?

Regarding the crash: I suspect there is some off-by-one problem because
when resizing the window (horizontally only) it often jumped by one line up.

And one more thing: I think the flags to chargrid_resize_new() are
superfluous as the flags shall be copied from the old chargrid.

Cheers,
- Vojtech



>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
>
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] HelenOS meeting at LinuxDays.cz?

[Vojtech Horky]

Hello, Jakub.

2016-10-03 22:46 GMT+02:00 Jakub Jermář :

> if there is enough interest, we can try to organize the next HelenOS
> meeting at LinuxDays.cz, during one of the free slots of the open room
> during Sunday, or after LinuxDays.cz closes.
>
Sounds good to me. Unless something unexpected happens, I would like to
join.

Cheers,
- Vojta
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 92nd HelenOS project meeting

[Vojtech Horky]

Hello.

2016-06-06 9:48 GMT+02:00 Jakub Jermář :

> The 92nd HelenOS project meeting will take place on Thursday of June 9,
> shortly after 19:00 somewhere in Prague, Czech Republic. Please let
> me know whether you plan to come

Please, count me in.

- Vojta
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 91st HelenOS project meeting

[Vojtech Horky]

Hello.

The 91st HelenOS project meeting will take place on Thursday of May 12,
>
Please, count me in.

- Vojta
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Ad coastline, 119 Fix relative include path (wrt. mainline, 2400)

[Vojtech Horky]

Hi Jiri.

2015-11-06 12:48 GMT+01:00 Jiri Svoboda :

> Hi Vojta,
>
> ###
> sed -e 's:#include "../../../common.h":#include :' -i
> "$HSCT_CACHE_DIR/include/abi/fourcc.h"
> ###
>
> I'm pretty sure there's a better way to do this.
>
Agreed. I should have named the commit a "workaround" rather than a fix.

I admit it was not the cleanest but the fastest way to get gcc and binutils
back to buildable state. There are a lot of other hacks in hstc.sh anyway
:-).


There are many headers in abi/ that suffer from the problem that they don't
> include what they use, hence a simple test:
>
> test.c:
> #include /header/
>
> whould fail to compile. I just fixed this one example I hit. It would
> certainly not do patching each and every one of them in hsct.sh. Why do you
> need to change the path? Is the relative path between the headers different
> when used in Coastline?
>
Yes. The reason is that common.h is somewhat special file. From userspace,
it is included via libarch/ where it is as a symlink.

hsct.sh copies all library headers to its own directory (to make it more
independent and also to allow for parallel builds for different platforms)
and this copy replaces symbolic links with actual files (which is okay and
it is much safer than possibly breaking the symlinks). Within this
so-called cache directory, common.h was not referenced/needed and thus was
never been copied there in the first place.

And since the name of the file is, well, common, hsct.sh does not copy it
to prevent possible name clashes [probably not an real problem but one that
could be difficult to trace].



> Then maybe we should not use the relative include path and instead include
> <[xx/]common.h> and pass -I  to the compiler.
>
I think common.h belongs to abi/ directory and shall be included by the
headers there as .

And maybe we can also split it into more files: it corresponds to limits.h
and inttypes.h in POSIX (maybe in C99 too).

Cheers,
- Vojta




>
> Cheers,
> Jiri
>
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
>
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 88th HelenOS project meeting

[Vojtech Horky]

Hello, Jakub.

2015-04-07 10:31 GMT+02:00 Jakub Jermar ja...@jermar.eu:

 The 88th HelenOS project meeting will take place on Saturday of April
 11, shortly after 14:00 somewhere in Prague, Czech Republic. Please let
 me know whether you plan to come so that I can make a reasonable
 reservation, no later than by Thursday evening. Also, do let me know
 whether you have any preferences for the venue of the meeting.


I plan to come. But with respect to MD's e-mail: I did very little in the
last (more than) half year. Thus my report would be very short.

- Vojta




 Jakub

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Some ideas for new GSoC projects

[Vojtech Horky]

Hi.

2015-02-10 21:30 GMT+01:00 Dominik Taborsky bre...@seznam.cz:

 How about a package manager and/or a package repo?

I am not sure that full-fledged package manager is a good GSoC project.
This is rather thesis topic because you cannot start coding right away.

You need to think about how to handle things such as multiple versions of
the same package or approach to software that does its own packaging (for
example, Ruby and its gems). Plus plenty of details regarding atomicity of
updates, rollbacking or the organization of the package database.

I think this would deserve some more discussions here on the ML. But if you
have something ready, go ahead :-).



 On 02/10/2015 09:21 PM, Jakub Jermar wrote:

 - Port Git to HelenOS
 - Extend BeagleBoard support (BeagleBoard Black, drivers)
 - Extend RaspberryPi support (drivers, the new RPi)
 - GUI improvements (toolkit, get rid of floats, there is a list of
 things to hack on the GUI somewhere)
 - USB ethernet driver
 - USB serial driver

 Comments?

 I would like to see there continuous testing. There is already the code
that accompanied Martin's thesis but AFAIK it does not have a simple way to
express more complex things, such as: type ls and verify words app, srv
and src are in the output. That is, something that could run QEMU, capture
its screen, OCR-it and then check it. Another point is in making this
easily deployable in Jenkins or similar tool.

One more thing came to my mind. It would be nice to have more first-patch
tickets there [1]. If you know about something simple and reasonable, do
not hesitate to create such ticket ;-).

@JJ: you are listed as the owner of most of these tickets probably because
you are the default owner for libc. Would you mind if I orphan these?


- Vojta

[1]
http://trac.helenos.org/query?keywords=~first-patchstatus=!closedorder=priority
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 86th HelenOS project meeting

[Vojtech Horky]

Hello Jakub,

2014-11-06 14:45 GMT+01:00 Jakub Jermar ja...@jermar.eu:

 I forgot about Jiri's request from the last meeting to move the meetings
 from Saturdays to Sundays, so let's see if Sunday works better.

please, count me in only if the meeting is on Saturday. I am already booked
for Sunday afternoon. Sorry for writing late.

- Vojta




 Jakub

 On 4.11.2014 23:15, Jakub Jermar wrote:
  The 86th HelenOS project meeting will take place on Saturday of November
  8, shortly after 14:00 somewhere in Prague, Czech Republic. Please let
  me know whether you plan to come so that I can make a reasonable
  reservation, no later than by Thursday evening. Also, do let me know
  whether you have any preferences for the venue of the meeting.
 
  Jakub
 
  ___
  HelenOS-devel mailing list
  HelenOS-devel@lists.modry.cz
  http://lists.modry.cz/listinfo/helenos-devel
 


 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] EDID testing

[Vojtech Horky]

Hello, Wolf.

2014-08-03 20:07 GMT+02:00 Wolf Ramovsky wolf.ramov...@gmail.com:

 Hello,

 I've just commited the WIP commit which introduces EDID support to
 vesafb driver. Driver doesn't yet build avaliable mode list, based on
 BIOS  monitor supported modes; it just writes mode lists to log.

I did a fresh checkout of your branch (is [1] correct?) but I am unable to
build it. It seems to me that you forgot to commit common.h file in vesafb
driver. Could you, please, check that? Thanks :-)

Cheers,
- Vojta

[1] lp:~wolf-ramovsky/helenos/vesafb


 Could you test it on real hardware?

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] FYI: GSOC 2014 wiki pages

[Vojtech Horky]

Hello all,
I created two wiki pages [1, 2] to track information related to projects in
the current GSOC.

Agnieszka, Wolf: feel free to add new content, especially documentation for
new utilities or list of things known not to work properly. Btw, your
branches do not compile for some of the architectures (but it looks to me
as only a wrong printf string somewhere and not-yet-committed-file problem).

Cheers,
- Vojta

[1] http://trac.helenos.org/wiki/RTL8169
[2] http://trac.helenos.org/wiki/VESA
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] [coastline] building libgmp issue

[Vojtech Horky]

Hello, Jakub.

2014-07-10 23:21 GMT+02:00 Jakub Jermar ja...@jermar.eu:

 Hi,

 I wonder if someone else is hitting the same problem when trying to
 build libgmp with the current mainline and coastline:

I just did a fresh checkout and I am not able to reproduce this.

From the error message, I would guess that you specified somewhere a
relative path instead of an absolute one. How does your hsct.conf look like?

- Vojta



 jermar@hexatonsil:~/software/coastline-amd64-build$
 ../HelenOS.coastline/hsct.sh build libgmp
  Caching headers, libraries and compile flags
  - Copying linker script and startup object file
  - Copying libraries
  - Copying headers
  - Fixing includes in libc headers
  - Saving config files
  - Copying extra headers and libraries
  - Fixing compiler flags
  Fetching sources...
  Building...
 [hsct]: tar xjf gmp-5.1.0.tar.bz2
  Patching gmp.h...
 ../HelenOS.coastline/hsct.sh: 38: ../HelenOS.coastline/hsct.sh: cannot
 open gmp-h.patch: No such file
 [hsct]: Error: Build failed!

 Jakub

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Montly report

[Vojtech Horky]

Hello, Wolf.

2014-06-26 11:21 GMT+02:00 Wolf Ramovsky wolf.ramov...@gmail.com:

  You should probably start by creating a completely isolated driver (you
  can call it vesa, vbe or something like that). Piggybacking on the
  kfb is fine for the proof-of-concept, but kfb is also used on non-PC
  platforms and therefore should not be polluted by the PC-specific code.

 Since it would be PC-specific driver, should I connect it to the
 rootpc rather than to rootvirt? If I should, how to do that? I see
 that drivers use .ma file, but I can't understand how to tell that
 vesa driver should be connected to rootpc.

In the same way rootpc adds PCI bus. See rootpc_add_functions() in
[rootpc.c].

But if the card is attached through PCI, it would make more sense to create
.ma file matching the device in a similar way as, for example, [uhci].

The first option is definitely simpler to start with, the second option is
probably cleaner as the device tree would represent more closely the
physical hierarchy. But the second option might be an overkill if we do not
have separate drivers for different cards/vendors.

- Vojta

[rootpc.c]
http://trac.helenos.org/browser/mainline/uspace/drv/infrastructure/rootpc/rootpc.c#L198
[uhci]
http://trac.helenos.org/browser/mainline/uspace/drv/bus/usb/uhci/uhci.ma




 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 84th HelenOS project meeting

[Vojtech Horky]

Hello Jakub,

2014-06-11 11:04 GMT+02:00 Jakub Jermar ja...@jermar.eu:

 The next meeting will take place on Saturday of June 14, shortly
 after 14:00 somewhere in Prague. Please let me know whether you plan to

I plan to come.

- Vojta
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Coastline turning official?

[Vojtech Horky]

Hello.

As we are moving stuff from the mainline to the coastline, I suggest 
we finally adopt the HelenOS Coastline as an official project. 
Therefore I have created a repository for it:


bzr://bzr.helenos.org/coastline
bzr+http://bzr.helenos.org/coastline

I believe Vojta should have the privilege to import the contents of 
his git branch into it.
Thanks, Martin. I will push the changes there as soon as I find some 
machine where bzr fast-import works ;-). If you wish to do it yourself, 
I certainly do not object.




Is there any practical reason why it needs to be in a separate source
code repository? Why can't it be in the mainline repository?

Perhaps not a practical reason, but it helps to keep the mainline clean
of any ported code. Making the HelenOS code a first-class citizen, a
distinction between ours and theirs. We can enforce different standards
on the two bases (cstyles, optimization options, warning levels, licesnes).

I agree.



On the other hand, it would be practical, to have coastline matrix
rebuilt every time there is a push to mainline, to see whether somthing
broke.


Sure. Once Vojta pushes his code to the official repo, I can write and 
debug some hooks for that.
That would be great. Just a sidenote: the rebuilding can take about 8 
hours if you rebuild everything for all architectures. And the packages 
are about 500MB in size (and require a few GBs during the build).


A follow-up suggestion: how about employing some continous-integeration 
software to run also tools/check.sh and once we integrate Martin's 
testing framework those tests as well?




Finally, should not be libposix moved to coastline as well? It has only
a very limited reason to exist without it.
Coastline was meant to be a repository for scripts for building someone 
else's code. libposix is our code.


Furthermore, libposix heavily depends on libc and, perhaps 
unfortunately, libc also has to be aware (to very little degree) that 
libposix exist. If we would have more similar libraries implementing a 
legacy API (e.g. a ncurses layer about our code or our libx11), then it 
would probably make sense to have a separate repository for them.


Because of this, I would prefer to keep libposix where it is.


- Vojta


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Jainja JVM for HelenOS

[Vojtech Horky]

Hello folks.

2014-04-28 21:33 GMT+02:00 Martin Decky mar...@decky.cz:

 I have created a Jainja harbour for the HelenOS Coastline (see attached),
 so that you can compile Jainja also outside the HelenOS source tree. Vojta,
 could you please add it to your Coastline repository?

Thanks, Martin. The build script is committed, I will regenerate the matrix
soon.

Guillaume: are there any specific changes to the source code different to
your mainline? As Martin already pointed out, the tarball is essentially a
prebuilt package and I would prefer that we would fetch as much vanilla
sources as possible and built them by ourselves.

For example, I think we can remove all the fdlibm files as we have a
prebuilt fdlibm available and we can make it a dependency to the coastline
script. Is there anything similar?




 BTW: Guillaume, have you tested Jainja with the latest HelenOS mainline
 (r2099)? It crashes with a page fault in jainja_util_Descriptor__equals__Lo
 (both on IA-32 and AMD64).

I can confirm this though I do not understand it. I was able to run Jainja
under IA-32 without problems not that long ago.

- Vojta




 M.D.

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] pcc harbour

[Vojtech Horky]

Hello Jakub.


2014-04-29 1:21 GMT+02:00 Jakub Jermar ja...@jermar.eu:

 Hi folks,

 I would like to move pcc from mainline to coastline. The first step is
 providing a harbour. Vojta, can you please review and consider the
 attached harbour for inclusion in coastline?

Thanks. The build script is committed, I made only two changes:

a) limited the parallelism to 1 as I encountered some problems for parallel
builds
b) add explicit checks that each application is built (|| return 1 inside
for-each)

I will regenerate the matrix soon.

Thanks!
- Vojta



 The harbour is extremely simple and makes use of the fact that pcc has
 already been ported to HelenOS and comes with preconfigured Makefiles.
 The harbour file tries to emulate the original HelenOS build
 environment. The harbour builds cleanly on amd64 and ia32 and most
 likely fails on others, even though there appears to be some rudimentary
 build support for also arm32, mips32 and ppc32.

 Thanks,
 Jakub

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] Missing sources for Testing Framework thesis

[Vojtech Horky]

Hello,
the branch with changes related to Martin Sucha's thesis are supposed to be
at

http://ho.st.dcs.fmph.uniba.sk/~mato/bzr/helenos-testing

But the host seems to be down and I do not know about any mirror.

Does anybody has a local copy of this branch? If yes, could you, please,
upload it somewhere (Launchpad, perhaps)?

Thanks!

- Vojta
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] gsoc code

[Vojtech Horky]

Hello Wolf.


2014-04-23 18:36 GMT+02:00 Wolf Ramovsky wolf.ramov...@gmail.com:

 Hi

 How should I public my GSoC project related code? Should I register
 repo somewhere or tarballs'll be OK?

Having a repo with your project is the best way to allow other developers
see your code and keep track of your progress. Launchpad [1] is fine with
us.



 P.S. Is it OK to send GSoC related questions to devlist?

Yes.


- Vojta


[1] https://code.launchpad.net/helenos



 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] RFC - a different (better?) way to test code in HelenOS

[Vojtech Horky]

Hello all.

TLDR version: I have a rather small library that ought to simplify testing
of C code [pcut]. I just tried to add it to HelenOS and convert some of our
tests to it. Result can be found in my [branch], interesting commits are
[libposix] and [bdsh]. I would be glad to get some feedback about it.
Thanks.


Long version:
Some time ago I was writing a small program in C and need to test that a
computation function works as expected. I admit that I am a bit spoiled by
JUnit for Java where you just add @Test to a method to create a unit test.
I hoped that something similar would be possible for C as well. But I was
not able to find a library/framework that would not require adding a lot of
extra code (e.g. [check]) or some kind of preprocessing (e.g. [aceunit]).
In the end I decided to try to implement something that would not need any
preprocessing (except $CC -E) and where adding new test would not require
changes at multiple places.

The result is PCUT [pcut]. There, writing a test is as simple as

#include pcut/test.h

PCUT_INIT

PCUT_TEST(test_name) {
/* Test code. */
}

PCUT_MAIN()

compiling and linking with libpcut.

I decided to bring this library to HelenOS because I think it might be
useful. Today, if you want to add a test of a (library) function to HelenOS
you can either write your own testing application (of course, sometimes it
is the best solution for various reasons) or extend app/tester. Both cases
means that the tests are far from the tested code and you need to do a lot
of setup. You either need to prepare a whole application and take care of
everything by yourself. Or you need to change (at least) 4 files in the
tester and hope that the environment would be okay after previous tests. I
guess this is (one of) the reason(s) why there are tests in libposix that
are commented out and are not run regularly [scanf].


The integration of this PCUT library to HelenOS can be found at Launchpad
[branch]. To build it, I recommend ia32 and do not forget to check the PCUT
option during configuration. The built tests are standalone applications
located in uspace/dist/test, their sources are under test/ together with
the library they ought to check. You can run them separately or run batch
test/run_all to run all the available tests. This run_all script not only
runs all the tests but also copies the output to /data/web and you can
access them through your web browser under /test.html. The output from the
test is in [tap] format (extended with standard output of the test).

The library itself is located in uspace/lib/pcut. It is a verbatim copy
from the Git repository and thus it includes also some files that are not
needed - such as Linux specific implementations. Having there only
HelenOS-related stuff would be better but that could be done later.

As an example, I created some tests in [libc], [libposix] and for [bdsh]
(yes, that is also possible as long as the functions are not static). The
tests for libc are rather hackish because of a great preprocessor abuse but
the other two are quite okay IMHO.


To briefly summarize why I think PCUT is a bit better than the current
state:
 * each library or application can have separate tests that do not
interfere with each other
 * moreover, each test case is spawned as a separate application and thus
the whole thing is immune against tests that really go bad (such as
null-pointer dereference)
 * adding a test to a library is rather simple and requires minimal effort
(see [bdsh])

I would be glad if you would find some time to go through the examples and
comment on it. If you like it, I would merge this to mainline and convert
some of the existing tests to it (where it makes sense). If you have some
ideas how to improve this we can iterate to some better version. Or if you
think the whole idea is wrong, I would discard it and eliminate all the
bits and bytes of the branch ;-).

Thanks!

- Vojta


[aceunit] http://aceunit.sourceforge.net/manual#d3e35
[bdsh]
http://bazaar.launchpad.net/~vojtech-horky/helenos/pcut-testing/revision/2095
[branch] https://code.launchpad.net/~vojtech-horky/helenos/pcut-testing
[check]
http://check.sourceforge.net/doc/check_html/check_3.html#Creating-a-Suite
[libc]
http://bazaar.launchpad.net/~vojtech-horky/helenos/pcut-testing/revision/2094
[libposix]
http://bazaar.launchpad.net/~vojtech-horky/helenos/pcut-testing/revision/2097
[pcut] https://github.com/vhotspur/pcut
[scanf]
http://trac.helenos.org/browser/mainline/uspace/lib/posix/source/stdio/scanf.c#L1224
[tap] http://testanything.org/
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 82nd HelenOS project meeting

[Vojtech Horky]

Hello, Jakub,

please, count me in.

- Vojta

2014-04-07 21:22 GMT+02:00 Jakub Jermar ja...@jermar.eu:

 The next meeting will take place on Saturday of April 12, shortly
 after 14:00 somewhere in Prague. Please let me know whether you plan to
 come so that I can make a reasonable reservation, no later than by
 Thursday evening. Also, do let me know whether you have any preferences
 for the venue of the meeting.

 Jakub

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] BUG!

[Vojtech Horky]

Hello Wolf.

2014-03-21 12:40 GMT+01:00 Wolf Ramovsky wolf.ramov...@gmail.com:

 2014-03-21 15:07 GMT+04:00, Vojtech Horky vojtech.ho...@gmail.com:
  Hello Wolf.
 
  2014-03-21 12:01 GMT+01:00 Wolf Ramovsky wolf.ramov...@gmail.com:
 
  Also
  in srv/net/dhcp/transport.c, line 182 and srv/net/dnssrv/dns_msg.c,
  line 535, in debug build, GCC says that variables size or q_size,
  respectively, is possibly uninitialized.
  I haven't explored for the rest possible uninitialized variable errors
  and just removed -Werror option in debug build mode, so fixing
  mentioned files could be not enough.
 
  What version of GCC are you using? It seems to me you are not using the
 one
  built by our toolchain script. Unfortunately, GCC ability to spot
  problematic places changes from version to version.

 I use gcc built by toolchain.sh, I see path to it in make output. It's
 version is 4.8.1.

I am not able to reproduce this. Can you, please, post here relevant output
from make? Which configuration are you using (default one for ia32 or with
some changes)? Also output from used-gcc -v might be useful.

Thanks!

- Vojta




 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] BUG!

[Vojtech Horky]

Hello Wolf.

2014-03-21 12:01 GMT+01:00 Wolf Ramovsky wolf.ramov...@gmail.com:

 Also
 in srv/net/dhcp/transport.c, line 182 and srv/net/dnssrv/dns_msg.c,
 line 535, in debug build, GCC says that variables size or q_size,
 respectively, is possibly uninitialized.
 I haven't explored for the rest possible uninitialized variable errors
 and just removed -Werror option in debug build mode, so fixing
 mentioned files could be not enough.

What version of GCC are you using? It seems to me you are not using the one
built by our toolchain script. Unfortunately, GCC ability to spot
problematic places changes from version to version.

Btw, can you file a bug report for this, please? Thanks. Preferably with
better name than $subject ;-).


P.S. I don't understand, how anybody able to build HelenOS. It's
 impossible in both debug and non-debug modes.

The truth is that we do not test non-debug builds that often. We definitely
should.

On the other hand, I have no problem building HelenOS for all architectures
by using the provided toolchain.

Cheers,
- Vojta





 2014-03-21 14:32 GMT+04:00, Vojtech Horky vojtech.ho...@gmail.com:
  Hello Wolf.
 
  2014-03-21 6:21 GMT+01:00 Wolf Ramovsky wolf.ramov...@gmail.com:
 
  In kernel/generic/src/mm/frame.c, lines 903 - 911:
  Variable avail, declared in line 904, exists only in debug build, but
  used
  in non-debug code, line 911
 
  Good catch. Fixed in mainline 2092. Thanks.
 
  Cheers,
  - Vojta
 
 
 
  ___
  HelenOS-devel mailing list
  HelenOS-devel@lists.modry.cz
  http://lists.modry.cz/listinfo/helenos-devel
 
 
 

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] GSoC project: Port the clang (LLVM) compiler to HelenOS

[Vojtech Horky]

Hi Esteban.


2014-03-13 18:01 GMT+01:00 Esteban Campostrini lesteba...@gmail.com:

 Hi Vojta,

 Thanks for the feedback.

  I have few comments.
 
  The code deserves some cleaning. I know it is still WIP state but I
 really
  do not want to merge it in this state.

 I made some cleaning. Basically I removed the unnecessary code.

Thanks! I pushed some of the patches to libposix to mainline which shall
further reduce the build() function.



  Btw, have you tried building for different architecture than ia32?

 Right now I'm trying to build for ia64. There was no problem while
 building HelenOS image, and
 the binaries that were built for ia32 with the coastline still run there.
 When I try to build HelenOS from the coast for ia64 it complains when
 is doing the configuration
 for ia64:
Configuration error: The presets are ambiguous
 I'm looking into this.

Can you be more specific, please? Is it reproducible with latest mainline?


Anyway, thank you one more time for the patches and build script. I am
planning to merge it this or next week.

Thanks,
- Vojta



 
  One final note. I know that the documentation for porting software to
  HelenOS is rather minimal (apart from existing harbours there are only
 few
  rants on my blog). That is why I tried to offer as much guidance as
  possible. But that won't be possible during the coding period if you are
  accepted into GSoC. Now, I was solving technical details for you and that
  won't work during the summer. But you are probably aware of this and you
  would plan accordingly in your application.

 Thanks for this note and yes, I'm aware of it. I know things haven't
 been quite smooth so far
 and I know that I still have several things to read and learn
 regarding the project chosen. I will try to be
 as realistic as possible regarding the proposal.


 Cheers,
 Esteban
 
 
 
  ___
  HelenOS-devel mailing list
  HelenOS-devel@lists.modry.cz
  http://lists.modry.cz/listinfo/helenos-devel
 

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] GSoC project: Port the clang (LLVM) compiler to HelenOS

[Vojtech Horky]

Hi Esteban.


2014-03-12 4:48 GMT+01:00 Esteban Campostrini lesteba...@gmail.com:

 
  This is rather weird. Because inside the file there is fpos_t and I do
 not understand how is it possible that it reports posix_fpos_t. At this
 phase it shall not see the posix_ prefix at all. What happens if you run
 only the preprocessor?

 My bad here, I replaced beforehand the occurrences of fpos_t with
 posix_fpos_t after grepping in HelenOS headers. I forgot to
 take that out to reproduce the original error. I'm sorry.
 This is actually the original error:

 contrib/tools/pngfix.c:868:19: error: field 'data_pos' has incomplete type
 fpos_t data_pos;  /* Position of first byte of chunk data
 */
^

This makes more sense :-). fpos_t is only a forward declaration so you need
to move the definition to the header.

Cheers,
- Vojta



 contrib/tools/pngfix.c:1550:19: error: field 'chunk_data_pos' has
 incomplete type
 fpos_t chunk_data_pos;/* Position of first byte of chunk
 data */
^
 contrib/tools/pngfix.c: In function 'zlib_check':
 contrib/tools/pngfix.c:2615:11: error: storage size of 'start_pos' isn't
 known
 fpos_t start_pos;
^
 I don't really get what is wrong, my guess is some header is missing
 but I'm not quite sure, stdio.h is included in pngfix.

  Actually, it is there:
  typedef struct _posix_fpos __POSIX_DEF__(fpos_t);
  and
  struct _posix_fpos {
  off64_t offset;
  };
  the problem is somewhere around this. But I do not see it now.

 Yes, I saw that and I replaced fpos_t with _posix_fpos since I thought
 the problem was that it couldn't find a declaration
 but it looks that there's something else to be done.

  I have a suggestion. How about forking the coastline repo and committing
 the harbour there (even if it does not work)? It would help me quite a lot
 when reproducing this. Regarding the patch to math.h - keep it there as
 well with comment that it has to be applied to mainline. How about that?

 I totatlly agree. I already forked it and commited the harbour, the
 patch and some notes.

 Cheers,
 Esteban

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Patch for #580 (Generate UUID according to RFC 4122)

[Vojtech Horky]

Hello Agnieszka.

2014-03-10 20:03 GMT+01:00 Agnieszka Tabaka nuf...@gmail.com:

 Hello :)

 Here is my GSoC qualification patch for ticket #580. It makes
 gpt_set_random_uuid() generate UUIDs conforming to RFC 4122 (version 4
 UUID). Can you review it?


Thanks for the patch. It looks good to me. I fixed the typo and pushed it
to mainline.



 PS I know that the patch is small and trivial - will it be sufficient?

I'll just extend a bit Jakub's answer: another goal of the patch is that it
may help you in assessing the complexity of your project. If the patch is
related to your project, your milestones and goals are based on more
reasonable assumptions about the code.

- Vojta




 Thanks,
 Agnieszka

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] GSoC project: Port the clang (LLVM) compiler to HelenOS

[Vojtech Horky]

Hi Esteban.


2014-03-11 4:17 GMT+01:00 Esteban Campostrini lesteba...@gmail.com:

 fdlibm as well as zlib are built and packaged before doing the build of
 libpng. The configuration phase ends with error after preforming the
 following checking:

 configure:12509: checking for memset
 configure:12509: /usr/local/cross/ia32/bin/i686-pc-linux-gnu-gcc -o
 conftest  -O3 -imacros
 /home/esteban/helenos/coastline/helenos/include/system_config.h
 -fexec-charset=UTF-8 -fwide-exec-charset=UTF-32LE -finput-charset=UTF-8
 -ffreestanding -fno-builtin -nostdlib -nostdinc -Wall -Wextra
 -Wno-clobbered -Wno-unused-parameter -Wmissing-prototypes -std=gnu99
 -Wwrite-strings -pipe -ggdb -D__LE__ -march=pentium -fno-omit-frame-pointer
 -I/home/esteban/helenos/coastline/helenos/include/posix
 -I/home/esteban/helenos/coastline/helenos/include/   conftest.c  5
 /usr/local/cross/ia32/lib/gcc/i686-pc-linux-gnu/4.8.1/../../../../i686-pc-linux-gnu/bin/ld:
 warning: cannot find entry symbol _start; defaulting to 080480a0
 /tmp/ccd5m53O.o: In function `main':
 /home/esteban/helenos/coastline/build/libpng/libpng-1.6.10/conftest.c:57:
 undefined reference to `memset'
 collect2: error: ld returned 1 exit status
 configure:12509: $? = 1
 configure: failed program was:

What I miss in the parameters are HelenOS libraries. If you look into
helenos/env.sh, in LDFLAGS you will notice linking with posixaslibc and
c4posix.

My guess is that LDFLAGS and CFLAGS are not used as one would expect. If
you look into other harbours, you will notice that most of the time, you
add the linker flags to CFLAGS, e.g.
CFLAGS=$HSCT_CFLAGS $HSCT_LDFLAGS_FOR_CC ...



 Here is not including any library from the same package like the case for
 example of libgmp in which you solved it by
 patching it, I'm not quite I understand what is trying to do here, I mean
 it seems to look for memset in libc but the prototype that declares
 is intentionally different.

This is one of the bits of ./configure magic I never really understood.
IMHO the point of this is to check that memset() looks as expected (i.e.
the signature). However, the check is often built in such way that it
passes even if the function is not defined at all. I encountered this when
porting GCC where configure found fork() even if the function did not
exist at all.


Btw, I briefly looked at help from ./configure and maybe you would need to
specify CPPFLAGS as well. You may want to look to Python harbour for a hack
how to do that.

- Vojta





  Anyway, I think you are making a good progress. I am glad you were able
 to fix the problems with hsct.sh yourself and I believe that you are only
 few details away from porting libpng :-).


 Thanks! I hope so!

 Cheers,
 Esteban


 Cheers,
 - Vojta


 [1] https://github.com/vhotspur/coastline/blob/master/libgmp/HARBOUR#L42
 [2] https://github.com/vhotspur/coastline/blob/master/gcc/HARBOUR#L90
 [3] https://github.com/vhotspur/coastline/blob/master/libmpfr/HARBOUR#L48
 [4] https://github.com/vhotspur/coastline/blob/master/zlib/HARBOUR#L57
 [5] http://helenos.alisma.cz/coastline/matrix/
 [6]
 http://trac.helenos.org/browser/mainline/uspace/dist/src/c/demos/hello/build.gcc


 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel



 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] GSoC project: Port the clang (LLVM) compiler to HelenOS

[Vojtech Horky]

Hi Esteban.


2014-03-10 2:22 GMT+01:00 Esteban Campostrini lesteba...@gmail.com:

 I'm using Mint and
 ls -l `which sh`
 lrwxrwxrwx 1 root root 4 Apr  5  2013 /bin/sh - dash

 After a little search I found that to avoid problems with bash scripts the
 shebang line should be set to #!/bin/bash (among
 other alternatives) so that made it.

My bad. I though hsct.sh was free of any bash-isms but apparently I used
source instead of dot . for sourcing other files. I fixed this and on
my system it works with dash now.



 The issue was again related to the path, the script sets the HSCT_HOME in
 a relative way and not in an absolute. By setting
 HSCT_HOME=$PWD it works, although I don't know if this can bring problems
 with other packages.

HSCT_HOME points to the directory with hsct.sh and all the harbours. This
variable is not used during the build so it shall not matter whether it is
absolute or relative. But I will look into this.

There is some magic involved when guessing the proper value that may not
work under all circumstances. If you use absolute path when calling hsct.sh
init ..., does the problem persist?

By the way, if you set HSCT_HOME to $PWD, it seems to me that you are
building in the source tree of coastline. That may work (I probably never
even tested that) but it is better to build in a different directory. That
way, you can build more architectures in parallel etc.


 I made an attempt to write a HARBOUR for libpng, this is what the build
 function looks like

 shipname=libpng
 shipversion=1.6.10
 shipsources=
 ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/${shipname}-${shipversion}.tar.gz
 

 build() {
  run tar xzf ${shipname}-${shipversion}.tar.gz
  cd ${shipname}-${shipversion}
  run env \
  CC=$HSCT_CC \
  CFLAGS=$HSCT_CFLAGS $HSCT_LDFLAGS_FOR_CC \
  LD=$HSCT_LD \
  LDFLAGS=-L/home/esteban/helenos/coastline/dist/zlib/lib\
  ./configure

  run make
 }


 The configuration process ends correctly but the testing executable
 'testpng' isn't built for HelenOS but for my system.
 I'm not quite sure why is this happening.

I tried this script on my system and the ./configure failed. I guess
missing --host switch [1] is the culprit as I was compiling on x86_64 for
ia32. This might also explain why it does not work on your system.

Also, sometimes, it is necessary to forcefully tell the ./configure script
that it is cross compiling [2].

libpng probably requires working math functions so you might need to
compile fdlibm as well. Also, there were some changes to libmath in HelenOS
recently and I have not checked yet whether that affects some existing
harbours.

By the way, if you use $HSCT_LIB_DIR in LDFLAGS, the script would be more
portable. See [3] and [4] for examples. (Of course, you first need to
install the files there by calling hsct.sh package zlib).




 In the big picture, what I'm trying to do is to generate the static
 library so then I copy it along with the corresponding header file into
 the right directories in the source tree of the OS. A good way of testing
 should be by trying to compile something from the
 OS itself. Is this something possible right now?

Yes, that is possible. However, it requires a bit more work than doing the
same job in, for example, Linux.

You can download a prebuilt GCC from [5] (unpack into overlay/) but be
aware that you have to specify some extra switches when running it inside
HelenOS (see [6]).


Anyway, I think you are making a good progress. I am glad you were able to
fix the problems with hsct.sh yourself and I believe that you are only few
details away from porting libpng :-).

Cheers,
- Vojta


[1] https://github.com/vhotspur/coastline/blob/master/libgmp/HARBOUR#L42
[2] https://github.com/vhotspur/coastline/blob/master/gcc/HARBOUR#L90
[3] https://github.com/vhotspur/coastline/blob/master/libmpfr/HARBOUR#L48
[4] https://github.com/vhotspur/coastline/blob/master/zlib/HARBOUR#L57
[5] http://helenos.alisma.cz/coastline/matrix/
[6]
http://trac.helenos.org/browser/mainline/uspace/dist/src/c/demos/hello/build.gcc
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] GSoC project: Port the clang (LLVM) compiler to HelenOS

[Vojtech Horky]

Hi Esteban.

2014-03-05 17:54 GMT+01:00 Esteban Campostrini lesteba...@gmail.com:

 Hi Vojta,

 I returned to the coastline. The first problems that I ran into seem to be
 related to
 the paths. The first one was related to the identification of the
 architecture done by the hsct.sh, it wasn't
 able to do it, it would complain when trying to initialize and build the
 image of HelenOS printing:

  Initializing this build directory.
  - Cleaning previous configuration in /home/esteban/helenos/mainline.
  - Configuring for ia32.
 Fetching current revision identifier ... ok
  - Building (may take a while).
  - Generating the configuration file.
  Caching headers, libraries and compile flags
 [hsct]: Error: Unsupported architecture: $(UARCH) = ''.

Looking at other symptoms I think you have not specified absolute path.
What was the exact command you run? From which directory?



 I solved temporarily that by hardcoding the architecture by setting:
 HSCT_UARCH=ia32
 It happened the same with the script that fetches the location of the
 linker, and again
 I temporarily hardcoded it to:
 _LINKER_SCRIPT=../mainline/uspace/lib/c/arch/ia32/_link.ld
 I did the same with the line 367 (the section that copies the headers)
 since it uses HSCT_UARCH:
 cp -L -R
 $HSTC_HELENOS_ROOT/uspace/lib/c/arch/$HSCT_UARCH/include/libarch/
 $HSCT_CACHE_DIR/include/

Again, this looks to me like some relative vs. absolute path problem.



 After those modifications the script builds the image without complaining.
 The image boots and seems to run OK.

 The next step is building the desired app. Since I'm using bash instead of
 sh I had to change the first line
 of the script to call bash (#!/bin/bash.)

I do not know which distro you use, but it is quite common, that

ls -l `which sh`
lrwxrwxrwx 1 root root 4 25. srp  2013 /usr/bin/sh - bash



 After all these changes I could build zlib and install it, all through the
 script. I remade the image of the SO and
 executed minizip with textdemo and it produced the expected output.

Cool :-). Good job.



 I tried with libgmp and this is the output I got:

 esteban@satellite ~/helenos/coastline $ ./hsct.sh build libgmp/
  Caching headers, libraries and compile flags
  - Copying linker script and startup object file
  - Copying libraries
  - Copying headers
  - Fixing includes in libc headers
  - Saving config files
  - Copying extra headers and libraries
  - Fixing compiler flags
  Fetching sources...
  - Fetching gmp-5.1.0.tar.bz2...
 --2014-03-05 13:49:00--
 ftp://ftp.gmplib.org/pub/gmp-5.1.0/gmp-5.1.0.tar.bz2
= `/home/esteban/helenos/coastline/sources/gmp-5.1.0.tar.bz2'
 Resolving ftp.gmplib.org (ftp.gmplib.org)... 37.252.124.96
 Connecting to ftp.gmplib.org (ftp.gmplib.org)|37.252.124.96|:21...
 connected.
 Logging in as anonymous ... Logged in!
 == SYST ... done.== PWD ... done.
 == TYPE I ... done.  == CWD (1) /pub/gmp-5.1.0 ... done.
 == SIZE gmp-5.1.0.tar.bz2 ... 2194942
 == PASV ... done.== RETR gmp-5.1.0.tar.bz2 ... done.
 Length: 2194942 (2.1M) (unauthoritative)

 100%[==]
 2,194,942171K/s   in 18s

 2014-03-05 13:49:22 (118 KB/s) -
 `/home/esteban/helenos/coastline/sources/gmp-5.1.0.tar.bz2' saved [2194942]

  Building...
 [hsct]: tar xjf gmp-5.1.0.tar.bz2
  Patching gmp.h...
 ./libgmp//HARBOUR: line 38: gmp-h.patch: No such file or directory
 [hsct]: Error: Build failed!
 ./hsct.sh: line 917: leave_script_err: command not found

Again: absolute path?

By the way, which version of coastline are you using? Current master (cddf875)
has only 912 lines.

If specifying the absolute would not help, please, send a brief description
of the directory layout you use (i.e. where is HelenOS checkout, where is
coastline clone and where you build) and maybe also some version info about
your system (Bash, GCC, ...). If the relative path was the culprit, I will
try to fix the script to handle this situation properly.

Thanks for the update.

Cheers,
- Vojta



 I tried to execute the patch command by hand and I got the same error.

 Anyway, there was some progress yay! =P
 I think I'll try to create a HARBOUR for libpng, and keep investigating on
 the 'patch' error. If
 you have a clue of what can it be I'll be thankful.

 Cheers,
 Esteban



 2014-03-05 4:13 GMT-03:00 Vojtech Horky vojtech.ho...@gmail.com:

 Hi Esteban.

 2014-03-04 16:37 GMT+01:00 Esteban Campostrini lesteba...@gmail.com:

 Hi all,

 Thanks Martin for the answer. Right now I'm trying to port a static
 library which I think involves a similar procedure
 to the one needed to export an app.
 Based on Vojta's blog on how to port apps I'm trying to start porting a
 static version of zlib and then a static
 version of libpng. I started using the coastline but it gives some
 errors, so since

 Can you, please, be more specific? What

Re: [HelenOS-devel] GSoC project: Port the clang (LLVM) compiler to HelenOS

[Vojtech Horky]

Hi Esteban.

2014-03-04 16:37 GMT+01:00 Esteban Campostrini lesteba...@gmail.com:

 Hi all,

 Thanks Martin for the answer. Right now I'm trying to port a static
 library which I think involves a similar procedure
 to the one needed to export an app.
 Based on Vojta's blog on how to port apps I'm trying to start porting a
 static version of zlib and then a static
 version of libpng. I started using the coastline but it gives some errors,
 so since

Can you, please, be more specific? What commands have you run? Was it error
message from coastline scripts or a failure during the build process?



 the porting of zlib
 should be fairly simple (I'm doing it for ia32) I resorted to the previous
 script (i.e. configure-for-helenos.sh.)

Ok, but please, be aware that I no longer update this script and that
coastline offers much better environment (packaging, installation into
HelenOS source tree etc.).


The thing is that when I execute the make, after invoking the script with
 the proper arguments (the ones
 from the blog), it gives me the following error msg:

 /usr/local/cross/ia32/lib/gcc/i686-pc-linux-gnu/4.8.1/../../../../i686-pc-linux-gnu/bin/ld:
 example: could not find output section .gnu.version_r

Looks to me that you are not using correct linker script. Can you, please,
post a complete output? Especially the output from ./configure and some
context before this error occurred.

I am aware that the documentation for porting software to HelenOS is rather
minimalistic at the moment. I started a new wiki page [1] but I am not sure
when I will find enough time to write a thorough guide. So, right now there
are only links to existing resources. New paragraphs/comments are welcome
:-).

Cheers,
- Vojta

[1] http://trac.helenos.org/wiki/PortingSoftware



 It looks like something is missing. Could you give me a hint on what can
 it be?

 Thanks in advance.

 Cheers,
 Esteban




 2014-03-03 11:33 GMT-03:00 Martin Decky mar...@decky.cz:

 Hello Esteban,


  Since I'm new at porting code I have a couple of questions:
 The idea would be 'rewrite' the code in order for it to use the subset
 of C supported by HelenSO right?


 If such changes would be minimal and well contained (e.g. in a rather
 small patch that could be applied automatically on the upstream sources),
 changing the upstream source tree is fine. On the other hand, you probably
 don't want to fork a wildly diverge the upstream libpng. Having such a
 diverged libpng would be of little benefit compared to writing our own PNG
 library.

 If you expect the required changes in libpng to be substantial, you
 should choose the other path -- extend the HelenOS native libc or the
 libposix compatibility library by functions that are required by linpng.

 Generally speaking it is really a matter of taste whether you prefer
 changing the ported library or extending the environment. But the ultimate
 goal should be the same in both cases: A clean and well-designed solution.


  In that case I have another doubt, the  library contains some files
 which easily exceed the 3K lines. This kind of task is generally done by
 inspecting line by line or some kind of automation can be achieved?


 The basic automation is based on link-time checks. If the library can
 link with the environment (libc, libposix), there is a reasonable chance
 that the environment will behave with respect to the library as expected
 (although there might be subtle differences, especially in corner cases
 (*)). You should use the test suite of libpng then to check for the
 behaviour compliance.

 If these automated steps fail you would have to resort to manual
 inspection of the code.

 (*) HelenOS is not POSIX compliant. Even the libc functions that have
 POSIX-similar names are not guaranteed to behave in a POSIXly compliant way
 (but they should behave reasonably). Even the functions in libposix are not
 guaranteed to be 100% POSIX compliant (since they might be unfinished). The
 keyword is best effort :)


 M.D.


 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel



 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] 81st HelenOS project meeting

[Vojtech Horky]

Hi Martin.

2014-03-03 14:14 GMT+01:00 Martin Decky mar...@decky.cz:

 Dear all,

 the next HelenOS project meeting will take place on Saturday of March 8th,
 shortly after 14:00 somewhere in Prague, Czech Republic.

 Please let me know whether you plan to come so that I can make a
 reasonable reservation, no later than by next Thursday (Mar 6) evening.
 Also, do let me know whether you have any preferences for the venue of the
 meeting.


Please, count me in.

- Vojta



 M.D.

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] GSoC project: Port the clang (LLVM) compiler to HelenOS

[Vojtech Horky]

Hi Esteban,

thanks for your interest in HelenOS and GSoC.

2014-03-01 23:41 GMT+01:00 Esteban Campostrini lesteba...@gmail.com:

 Hello everybody,

 I'm an undergraduate Argentinian student and I'm interested in
 contributing to
 the project through GSoC in the particular topic:

 Port the clang (LLVM) compiler to HelenOS

 I have good knowledge of C and C++, I'm also familiar with the basics
 phases
 behind compilers (I had to write one for a course and I worked in a
 highlevel one
 as a research assistant.)
 I know this project involves other things such as LLVM and the toolchain
 of HelenOS itself
 with which I'm not very familiar at the moment, so I think that fixing
 some bug
 is a good way to get familiar with the codebase and also to give you the
 opportunity to asses
 my skills regarding the project. Could you give me an opinion on which
 deffect or enhacement from the list available in the page you think is most
 suitable for this?
 And off course, any other suggestion is welcomed ;)


First of all, we do not require that the entry patch have to be based on
the project you propose. Thus, any issue from the [list] would be fine.

If you want to contribute with patch directly related to this topic, I
think following might work well:

If you are familiar with LLVM, you may try to update the Makefiles to
support Clang for other architectures (currently, the Makefiles are ready
only for PC and Sparc). If you wish to investigate this possibility, be
prepared that it may not be possible to compile all files with LLVM. It is
quite possible that we use some GCC-ism somewhere and that you would need
to combine these two toolchains.

Port some simple library/application to HelenOS. This would expose you to
the issues related to porting applications to HelenOS (you may want to read
through some of the links added to [574]). It may also help you in
estimating a roadmap for you project.
The library/application you choose does not need to be connected to LLVM. I
would say that, for example, libpng could be a good candidate. It is not a
large library, shall not require any special functionality and has a single
dependency (zlib) that was already ported.

Cheers.
- Vojta


[list] http://trac.helenos.org/wiki/HowToContribute
[574] http://trac.helenos.org/ticket/574

Thanks in advance.

 Best,

 Esteban

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] GSoC 2014 - new ideas

[Vojtech Horky]

Hello,
the deadline for GSoC application is this Friday and the list of ideas
[gsoc14] is still not very long. Furthermore, the tickets there are
recycled ones from previous years. Maybe we shall drop some of them and add
some new ones. I am sending a few ideas that might be interesting for
GSoCbut I would like to hear second opinion as well.


New programs/servers
* our own FTP server
* bdsh improvements (loops, variables, pipes)
* interactive partition editor
* taskbar (i.e. list of open windows, launcher, clock)


Porting
* Bazaar. We have Python thanks to Zbigniev but it is a bare interpreter.
This would mean adding all the functionality needed to run bzr.
Unfortunately I am not able to predict how much work that could be.
* Finish GCC porting. There are two bigger topics: first, make gcc a truly
native compiler (i.e. no need for -nostdlib etc. flags) and, second,
update the ported GCC to the newest version (that would mean bringing C++
support to HelenOS). Again, I am not sure about the difficulty.
* ncurses. Maybe it is not the best API around but it would allow us to
port interactive applications.
* IUP toolkit. Last year we discussed [ml-gui] some problems with porting
of GUI toolkits but it still might be doable.


Drivers
* I already created ticket [571] for graphical output on Raspberry Pi. But
it still needs polishing.
* Network over USB (also on Raspberry Pi)


Other
* Installer wizard. I mean something with nice interface that would help
the user install HelenOS.
* There are also ideas on our wiki page [ideas]


So, which ones of these shall we promote for GSoC? Or, are some of these
inappropriate for GSoC because of their difficulty? Or do you have some
other ideas that would be worth suggesting?

Cheers,
- Vojta



[gsoc14] http://trac.helenos.org/report/21
[ml-gui] http://lists.modry.cz/private/helenos-devel/2013-March/006368.html
[571] http://trac.helenos.org/ticket/571
[ideas] http://trac.helenos.org/wiki/ContemplatedFeatures
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] GCC, Python and other goodies

[Vojtech Horky]

Hi, Jiri.

2013/12/17 Jiri Svoboda jirik.svob...@seznam.cz

 Hi Vojta,

 I really aplaud your achievements and I am looking forward to trying it
 out :-D. On the other hand I really don't understand your separatist
 tendencies. Why use a separate private issue tracker on GitHub and a
 separate private repo on GitHub? IMO coastline should be either merged to
 mainline. Even in the case we actually decided to keep it in a separate
 repo (why?) then why not host it on the official server along mainline. And
 why not use the projects main issue tracker?


I do not have any separatist tendencies :-). The current state only
reflects the evolution of the coastline. It started as a bunch of scripts
for building GCC for HelenOS. At the beginning, I really did not care about
other packages etc. and it was a set of small ugly scripts (opposite to the
current situation when it is one big ugly script). I was also doing changes
in libposix (that I tried to merge regularly) and I did not want to pollute
the mainline with these helper scripts. Hence a separate repo. And since I
expected it would be a (very) temporary solution, I really did not care
whether I use the same versioning tool as the mainline or where would I
host it.


Regarding the issue tracker: I am not 100% sure that we want to pollute
Trac with groups of tickets such GCC does not compile on xy yet. Just my
opinion, I really do not care where the tickets are stored as long as I can
see a list of them :-).


The integration: I would prefer a separate repository just to keep mainline
clean with strictly BSD code only. But maybe scripts working with GPL
code are okay?

Anyway, I do not want to end in the same situation as is currently with
binutils, PCC and MSIM when they are part of the build process and probably
no one builds them regularly as they slow down the building unacceptably.


Hosting: I used mine because I simply had access to it. I agree that it
would be definitely better to have it somewhere under helenos.org (at least
I would get back those 500MB all the tarballs currently occupy) to give it
a more official mark.

I still consider coastline as an experimental script, but if we decide to
make it somehow part of mainline, we should also discuss some related
issues. First of all, what is the idea of packaging in HelenOS in general?
At least in rough outlines such as approach like Gentoo vs Fedora vs
Windows.

Next issue: until installation to disk is possible, would the packages be
installed during the build process or would they be downloaded/installed at
runtime (btw, we have all the applications to do that, we just need to put
them together)?

A related question is some kind of automatic testing. It would be great to
have an automatic re-generation of these packages + continuous integration
that would at least verify that the compiled binary can be run (e.g. GCC
prints version and compiles a hello-world). Even now (with only 10 ported
packages), testing that ia32 works okay requires a non-trivial amount of
time.


I hope all this makes sense ;-).

-  Vojta



 Best reards,
 Jiri

 -- Původní zpráva --
 Od: Vojtech Horky vojtech.ho...@gmail.com
 Datum: 17. 12. 2013
 Předmět: [HelenOS-devel] GCC, Python and other goodies

 Hello,
 just a short information regarding status of some ported software.

 First of all, I uploaded a lot of pre-compiled packages onto [1]. Just
 download the tarball, unpack it into uspace/overlay, rebuild and you are
 ready to go.

 I wrote few notes about the matrix on my blog [2] if you are interested in
 details. The matrix is generated using my coastline scripts [3].

 If you have some time to spare, I would be grateful if you would download
 the packages and try them. Feel free to send bug reports either as replies
 to this thread or directly to the issue tracker at GitHub [4].

 Currently available binary packages include GCC + dependent libraries,
 binutils, MSIM, fdlibm and Python (thanks to Zbigniew Halas).

 - Vojta

 [1] http://helenos.alisma.cz/coastline/matrix/
 [2]
 http://vh.alisma.cz/blog/2013/12/08/helenos-coastline-updates-status-matrix/
 [3] https://github.com/vhotspur/coastline
 [4] https://github.com/vhotspur/coastline/issues

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] New development, guilang

[Vojtech Horky]

Hi, Sergio.

2013/12/14 Sergio Tortosa Benedito serto...@gmail.com

 Hi guys, I'm writing this e-mail to announce a new project I made, which
 it's called guilang.
 First, guilang it's an extension (I don't know really how to describe
 it) for the Lua programing language, it makes Lua a declarative,
 event-driven language which aims to make it very easy for developers to
 write applications. Second, applications written in guiLang are
 platform-independent and toolkit agnostic, this is thanks to the fact that
 guiLang has three parts the launcher (made for making live easier), the
 guilang core (which implements all the logic needed for guiLang) and the
 gui constructor (which is the responsible for translating guiLang to the
 toolkit).
 I think that guiLang it's not only a win for developers, but also a direct
 win for users in platforms with more than one toolkit (namely Linux/BSD)
 since the same program can run not only on differents toolkits, but also on
 libraries which add own widgets (e.g: pure qt and kde).

I do not know Lua so please, forgive me if I missed something, but how
would be the code binded to the GUI? For example, how would the source code
change if, for example, on clicking the button a new window with Hi! text
is supposed to appear? Is the exampleApp.lua only GUI description and the
code resides someplace else?

And is my understanding correct that the guilang toolkit would be
basically a simplified interface to the common functionality of all the
underlying toolkits?



  GuiLang, was made initially with HelenOS in mind however, I later saw
 it's cross-platform possibilities.

 For trying this you'll need luajit/lua (it's recomendable that you choose
 lua 5.1 over 5.2 for two reasons: 1.for keeping compatibility with luajit
 2.because I had problems with 5.2 (i dont remember if what I had trouble
 with was luarocks or lgi or both)), you'll also need lgi which you can
 install it via luarocks or directly. The code it's in
 lp:~sheosi/+junk/guilang.Note: although guiLang itself its crossplatform
 the code it's right a proof-of-concept and only supports gtk, what's more
 it only supoprts windows and buttons, however neither of both should take
 long for adding more.

The code of the application itself looks pretty simple and readable. But
one more question comes to my mind. HelenOS runs on several platforms and
their display resolution differs a lot. Some of them do not provide a
graphical (pixel-oriented) output at all. Thus, specifying width of any
control in pixels may not be the best solution. At least, not for all
architectures. Do you plan some kind of switchable layouts depending on the
resolution or other ways to tackle this?

Btw, I looked at your Lua branch and you do not need to add the setjmp for
amd64 as there is a generic implementation in mainline since rev. 2041.

Best regards,
- Vojta



 I'll be waiting your feedback, Sergio.



 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Multiple definitions

[Vojtech Horky]

Hi, Sergio.

2013/12/15 Sergio Tortosa Benedito serto...@gmail.com

 hi again, I would like to get help from you, since I'm stuck again on
 porting lua to helenOS, when my compiling the branch I'm working on
 (lp:~sheosi/helenos/lua) the compilers encounters duplications on
 everything, I think it's beause of the makefile but I'm failing to find
 where the error is. Does anyone have any clue?

It is problem with your Makefile. In the variable SOURCES you shall have
list of source files that make up the application. But only the .c files,
not the headers.

First of all, they are redundant as dependencies are handled automatically
by makedepend.

Next, they cause the duplications. Following happens. In your Makefile, you
have:
LUA_O= lua.h lua.c ...
SOURCES = $(LUA_O) ...
In Makefile.common, variable OBJECTS is constructed by substitution of the
extension by .o. Thus,
OBJECTS := lua.o lua.o ...
and finally, the application is produced by call to
$(LD) $(OBJECTS) $(LDFLAGS)

Thus, every manual dependency on lua.h would trigger addition of the lua.o
object to the binary.

Hope this helps.
- Vojta




 Thanks, Sergio.

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] ad-hoc meeting next week?

[Vojtech Horky]

Hi.

2013/8/7 Jakub Jermar ja...@jermar.eu

 On 7.8.2013 11:27, Ján Veselý wrote:
  the candidate days are Tuesday and Wednesday

 Tuesday does not work for me, Wednesday does.

Unless I missed this by a whole week, I would like to join you as well.

- Vojta



 Jakub


 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] #91 socis 2013

[Vojtech Horky]

Hello, František.

Dne 2. srpna 2013 6:09 frantisek haas frantisek.h...@gmail.com napsal(a):

 Zdravim,

 Jmenuju se Frantisek Haas, studuju softwarove systemy na MFF a rad bych se
 zapojil do vyvoje HelenOS. Budu podavat prihlasku do programu SOCIS 2013.

 V priloze posilam navrh na ticket #91. Jedna se o utilitu pager do
 kconsole, ktere se da nastavit pocet radku a po jejich dosazeni prestane
 vypisovat vystup az do stisknuti klavesy. Prestanou se vypisovat pouze
 prikazy obsluhovane vlaknem kconsole. Doufam, ze se mi primerene povedlo
 dodrzet stabni kulturu a implementovat to rozumne. Budu rad za pripominky.

I do not see any attachments in this e-mail :-).

And, please, use English in this mailing-list (despite the Czech domain and
Czech-speaking admins). Thanks a lot.

Cheers,
- Vojta Horký



 S pozdravem,
 FH

 P.S.
 Do mailing listu cz nebo en?

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] [PATCH][ticket #91] kconsole: simple pager

[Vojtech Horky]

Hello, Marin Ramesa.

2013/7/27 Marin Ramesa m...@hi.t-com.hr

 On 18.07.2013 09:25:23, Vojtech Horky wrote:
  Just a sidenote: if you are more interested in the microkernel
  programming, there are also tickets that are for kernel - such as
  #91 or #466 - but they do not target the more complex parts
  (e.g. memory or thread management).

 I've tried something with #91. But in the end I'm not sure if I done it
 correctly. Maybe there are too much additions to existing code.
 For example, I added a character buffer to outdev and wrote an
 outdev_push_character() routine for it, I don't know if this was a good
 idea. I added a new command 'pager' to console. Modifed stdout_write()
 to use the new buffer if the buffering is on and there is an existing
 console command that requested the use of the buffer, with this patch
 there is one if statement more in stdout_write(), it still passes the
 kernel printf string test.

 snip

 Anyway, as far as I tested, the pager is working. To use it enter
 'pager' in kconsole, or 'pager -p' for prompt mode. Output of the next
 command will get buffered and paged. In ordinary mode ENTER is to
 scroll one line down and SPACE is to view the next page. In prompt
 mode, UP and DOWN are for moving inside the buffer and Q is to quit the
 pager prompt mode.

Thanks for the patch. I like the extension with the scrolling but I also
have some remarks.

The code formatting looks okay to me, except we do not start else on a
separate line.

The patch does not compile on all architectures (you can use
./tools/check.sh to compile HelenOS for all supported targets) - it seems
to me that the percentage computation in the scroll mode is at fault. We do
not have floating point numbers in kernel.

I was not able to use the pager for some commands. For example, running
pager followed by test slab2 would not invoke the pager correctly (in QEMU
on ia32).

Maybe your approach is too complex because you try to solve more problems
all at once. For example, the up/down scrolling is a very nice feature but
for the kernel console, the paging alone could be enough. Especially if it
works for any command issued.

Cheers,
- Vojta





 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] [PATCH] bdsh: add numbering of all output lines to cat

[Vojtech Horky]

Hello, Marin Ramesa.

2013/7/18 Marin Ramesa m...@hi.t-com.hr

 I listened to Jiří's suggestion and started with the outer layers of
 the system. This is more suitable for a beginner. As I don't know much
 about servers, I started with a simple modification of bdsh's cat and
 added an option for numbering all output lines. With this patch you can
 do 'cat -n textdemo textdemo' or 'cat --number textdemo textdemo'.

Thanks for the patch, it looks good. I made some small changes to it and
pushed it to the mainline (rev. 1897).

Just a sidenote: if you are more interested in the microkernel
programming, there are also tickets that are for kernel - such as #91 or
#466 - but they do not target the more complex parts (e.g. memory or thread
management). They might be good starting points for kernel hacking. Just my
$0.02.

Thanks again for the patch.
Cheers,
- Vojta



 This
 might be useful when bdsh gets scripting support.

 Martin, thank you for a detailed explanation and review. I will have it
 in mind when I work on that task in the future, if my knowledge of the
 system gets to that level. And also Jakub's comment, as I managed
 to cause failed assertions in kernel code from userspace code, which
 was strange to me, besides the fact that the solution was too easy, as
 Jiří noticed.

 Anyway I think I properly tested this patch with all the cat's options.
 So, here it is.

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Framebuffer problems

[Vojtech Horky]

Hi, Petr.

2013/4/19 Petr Koupý petr.ko...@gmail.com

 It could be prevented by putting artificial barriers on viewport edges
 but such solution is not consistent with the notion of infinite desktop
 with possibly several separated (non-touching) viewports. Another

How about restricting the mouse to the smallest rectangle still covering
all the viewports?

For the simplest - and today virtually only one used - scenario, where
there is single viewport identical with the physical monitor, such
restriction would effectively limit the mouse to the screen. For more
complex scenario, it would at least ensure that the mouse does not stray
too far away.

Not talking about the advantage that having the boundary allows you to put
buttons there (such as main menu etc.) and you know that they will be
easily reachable. You only need to move the mouse in their direction
(without great precision) and the mouse would stop on the screen border -
just above the button :-).



 possibility (which I like more) is to simply introduce a keyboard combo
 that
 would rescue the mouse pointer by resetting it into the center of the
 active viewport.

It seems like an ugly hack to me. But I understand that it is probably the
simplest way around it.

- Vojta





 Petr

  From: HelenOS-devel [mailto:helenos-devel-boun...@lists.modry.cz] On
 Behalf Of Jiri Svoboda
  Sent: Friday, April 19, 2013 8:37 AM
  To: HelenOS development mailing list
  Subject: Re: [HelenOS-devel] Framebuffer problems
 
  I encountered a similar problem recently, sometimes (seems especially
 when I un-grab Qemu input and then re-grab it) mouse pointer disappears
 (and presumably the mouse is rendered inoperative). I didn't try with
 keyboard. I am not sure whether the keyboard works at that point or not. I
 am not able to consistently reproduce this problem, it occurs from time to
 time.
 
  -Jiri


 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] GSoC post-mortem IRC meeting

[Vojtech Horky]

Hello,

2013/4/15 Martin Decky mar...@decky.cz

 Hi folks,

 due to unfortunate and unforeseen reasons I cannot make it to the IRC
 meeting where the organizations not accepted for this year's GSoC should
 receive some general feedback. If there is someone who is able to attend,
 please do so. Here are the instructions from Google:

Here are my notes and impressions from the meeting. I was talking with
Carol and the summary message is that we did okay but they just could not
accept all organizations that apply.

In more detail: there were a lot of OS organizations this year and
apparently Google wants the spectrum of organizations (types) as wide as
possible. So, not all OS organizations were accepted this year. Even Minix
didn't make it. AFAIK only Illumos and RTEMS made it through. Another thing
is that a lot of new organizations were accepted this year and quite a
number of veterans weren't accepted because of that.

Our application and ideas page was okay. Citing Carol, i like that you
have it broken down with required skills and possible mentors and all that.

I also asked whether the fact that last year from 5 projects only 2 passed
the final evaluation has any impact on our rejection this year. It looks
that this does not influenced the decision. Which shall not be, after all,
a surprise if GSoC should be about writing good code.

Carol also said that we should apply next year.

That is all, there wasn't much to ask once I learned that we weren't
accepted simply because of the amount of orgs that applied.

- Vojta





 If you would like some general feedback on why your organization was not
 accepted, please consider attending the IRC meeting in #gsoc on Freenode on
 Friday, April 19, 2013 at 16:00 UTC.


 M.D.

 __**_
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/**listinfo/helenos-develhttp://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Python port

[Vojtech Horky]

Hi Zbigniew,

2013/4/3 Zbigniew Halas zha...@gmail.com

 On Tuesday 02 April 2013 19:41:02 Jakub Jermar wrote:
   Then boot HelenOS and enjoy Python!
 
  and Python I enjoyed! Thanks for working on this.

I concur. Nice job. I have no problem building the Python using the
instructions you provided.



 Welcome. I guess it's time to work on something more serious now ;)

  How do you get the new binary and the python2.7 library to the
  initrd.img? For me, this was not very convenient as I had to prevent
  make in the boot subtree from cleaning up uspace/dist first.

 I made some nasty ad-hoc hack to the Makefile.

I think we should introduce some target to do just this - repack the
uspace/dist and produce the final image without cleaning the directory
first. I think I will hit the same problem soon with my effort around
porting GCC.




  I used the new 4.8 toolchain to build Python and it produced a great
  deal of warnings, fortunately the compilation completed just fine.

 Yeah, but it actually has almost all possible warnings enabled and it's not
 much different from Python compilation for Linux with the same flags,
 although
 probably there are some extra warnings worth fixing.

Just a footnote: compiling with GCC 4.7.2 produce warnings for almost each
file as well.


  The patches look reasonably small and the overall amount of changes is
  pretty small too, which is nice. Unless someone has some serious
  concerns, I would like to integrate this.

 Great, thank you!

The patches look good to me too. I didn't know that the floating point
constants are actually built-ins like this - it renders my approach in the
gcc-port branch [1] quite naive ;-).

I also looked at the changes you made to the Python source code and I am
really surprised that the diff is so small. Moreover, half of the changes
came from the need to rename posix_ to pyposix_. By the way, I already
removed this posix_ prefixing in libposix in my GCC branch so in the future
such problems would not need to be solved.

Thanks!

- Vojta


[1] https://code.launchpad.net/~vojtech-horky/helenos/gcc-port



 Zbigniew

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Preparing tickets for GSoC 2013

[Vojtech Horky]

Hello,

2013/3/11 Jakub Jermar ja...@jermar.eu:
 On 03/11/2013 05:37 PM, Martin Decky wrote:
 Not that I have anything against driver-related ideas, but I suggest
 that we somehow group such tickets on the ideas page to make it more
 clear that they are related and that implementing drivers for other NICs
 than listed is possible.

 My original idea was to group the related ideas by their category, which
 is what the current listing does. I agree that we could, especially if
 the groups get yet a little bit bigger, separate the groups more visibly.
There is almost 20 tickets now so I decided to try the grouping.

Even if a component has a description and in the Custom query you
choose to group by the component, this description is not displayed.
So just adding descriptions to the categories is not enough.

Thus I decided to extend the page with the inline TicketQuery macro
and do the grouping manually in the text. You can see the result
online [1]. Apart from the fact that the texts would require quite a
lot of polishing, it also makes the page quite long. I put some of the
listing in the short format, some of them in a table one to allow
comparison.

What do you think? Do we want it like this or does this inspire
someone for a better solution? If it looks ugly, feel free to remove
it. It is just an idea what to do with the idea list.

Vojta

[1] http://trac.helenos.org/report/19


 Jakub

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] 73rd HelenOS project meeting postponed

[Vojtech Horky]

2013/3/8 Jakub Jermar ja...@jermar.eu:
 On 8.3.2013 10:57, Jiri Svoboda wrote:
 sorry for late response. I would like to attend the meeting, too (with
 about 80% confidence). Can we cancel the cancellation ? :-)

 I guess we can still do that if Vojta has not already planned something
 else.

 Vojta?
Fine with me, I haven't planned anything else. See you tomorrow.

- Vojta


 Jakub





 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] 73rd HelenOS project meeting

[Vojtech Horky]

Hi Jakub,

2013/3/4 Jakub Jermar ja...@jermar.eu:
 The next meeting will take place on Saturday of March 9, shortly
 after 14:00 somewhere in Prague. Please let me know whether you plan to
 come so that I can make a reasonable reservation, no later than by
 Thursday evening. Also, do let me know whether you have any preferences
 for the venue of the meeting.
I am planning to come. I have no special preferences, something
reachable via underground would be nice.

- Vojta


 Jakub

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] putting HelenOS-related project on launchpad

[Vojtech Horky]

Hi, Jana,
2013/2/15 Jana Rapava ferma...@gmail.com:
 Hi,
 I'm working on network autoconfiguration in HelenOS for my bachelor thesis,
 and would like to put the code on launchpad.
I was a bit impatient to see how the autoconfiguration would work so I
checked out your branch. It looks I will need to wait a bit longer
;-).

However, I noticed that you have a lot of debugging prints there using
plain printf for that. We have a simple logging system available [1]
so you may consider using it instead. It offers printing at several
verbosity levels and allows you to create hierarchical log-groups.
Downside is that it prints the logs to the file instead of the screen
(stdout) but it is trivial to change that in libc. Then, you would not
need to pass the verbose flag to each of your functions.

By the way, there is getopt implementation in libc which may simplify
your arguments handling a bit. And AFAIK stdout is line-buffered, thus
the flush() is not necessary. Not that it would cause any harm.

- Vojta

[1] http://trac.helenos.org/wiki/Logging

 Should I create a separate project, or import my branch here
 ( https://code.launchpad.net/helenos )?
 Thanks,
 Jana Rapava

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] New Tickets Filing

[Vojtech Horky]

Hello Manish,

2013/1/21 manish sharma manish09.iitroor...@gmail.com

 Hi !!

 I have recently started exploring Helen OS with user guide
 http://trac.helenos.org/wiki/UsersGuide .

 While Exploring I found some trivial bugs , so I filled new tickets,
 Please have a look at these tickets.


Thanks for reporting these.

I just briefly tried to run latest mainline and also our last release and I
was not able
to reproduce those bugs. Could you, please, include more details (just add
them
as comments to the ticket). The following information would be extremely
useful:

Are you running from a prepared image (i.e. from
http://www.helenos.org/download)
or you compiled from source? In both cases - what is the architecture
(ia32/amd64/...)
and which version do you have (e.g. 0.5.0 or revision number).

Are you running inside QEMU or other emulator or on bare metal?

What kind of keyboard are you using? For example, is it a USB one?

Thank you very much.

Regards,
- Vojta



 1)
  #510 http://trac.helenos.org/ticket/510 Switching between Virtual
 Console using F1-F11 key http://trac.helenos.org/ticket/510
 2)   #511 http://trac.helenos.org/ticket/511 Keys not work in some 
 caseshttp://trac.helenos.org/ticket/511


 Manish Sharma
 B.Tech,CSE ,IV year, Indian Institute of Technology Roorkee.
 +91-7579048744

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Reminder: last day for FOSDEM talk proposals

[Vojtech Horky]

Hi Jakub,

2012/12/14 Jakub Jermar ja...@jermar.eu:
 Hi,

 looks like there are already several HelenOS talk proposals, but the
 most obvious one, i.e. HelenOS update is still missing. Any plans
 regarding the 'update' talk?
After the last meeting I expected you, Martin or Jiri are planning to
have this talk.

I can probably do this talk myself but I do not want to steal it from
you. So: who wants to do it or shall I send the proposal?

- Vojta


 Jakub

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Bithenge constraint proof-of-concept

[Vojtech Horky]

Hello, Sean
and welcome back :-).

2012/11/30 Sean Bartell wingedtachik...@gmail.com:
 Hello, everyone,

 After a few months off, I recently resumed work on Bithenge. As you may
 recall, Vojtech was especially interested in code generation and editing
 support, but I didn't manage to figure out how to implement them during
 GSoC. I've been working on a constraint-based design for Bithenge that
 should help make these features possible. A partial proof-of-concept is
 attached; it requires a recent version of Python 3, and converts a
 trivial Bithenge transform into a Python encoder and decoder.
I see that you extended the demo for structs - it looks pretty good.
It might be interesting (later on) to convert some of our utitlities
(such as mkfat.py) to use Bithenge. Currently they use a wrapper above
the struct.pack() and the syntax is rather limited AFAIK.

 For now, I'm going to keep working on the proof-of-concept and figuring
 out other crucial features, like conditionals and repetition. It's going
 to take a while to figure out how to solve those things for flexible
 encoding and decoding.
Keep us posted, please.

 Finally, a note on languages supported by HelenOS. The Bithenge design
 (old and new) relies on object-orientation and reference counting, and
 it was tedious to write in C. When I start working on the full new
 version of Bithenge, I'll probably want to use C++ or Python instead.
 Bithenge wouldn't be usable within HelenOS without full C++
 (#413-related) or Python (#403) support, although it could still
 generate C code to be used in HelenOS.
As I already wrote to you in some of our previous e-mails, it is ok to
use Python or C++. Eventually, we would like to support both so this
could be another reason to do so. And for the code generation we can
use it in cross-compile mode when the actual generation would happen
on the host machine.

A side note - support for C++ is not preconditioned by a working GCC
in HelenOS. We can also do a cross-compilation - we just need
implementation of the standard C++ library for HelenOS (i.e. the
runtime part).

And my last cent - I would go for Python rather than C++ because IMHO
the code would be more readable in Python. And extending it (for
example with code generators for different platforms/languages) would
be simpler.

Cheers,
- Vojta



 Thanks,
 Sean Bartell

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] GUI improvements

[Vojtech Horky]

Hello Petr,

2012/11/29 Petr Koupý petr.ko...@gmail.com

 Hello,

 just to let you know, the lp:~petr-koupy/helenos/gui-optim branch is prepared
 for merging into mainline. Among others, it resolves the following tickets:

 http://trac.helenos.org/ticket/478
 http://trac.helenos.org/ticket/482
 http://trac.helenos.org/ticket/483
 http://trac.helenos.org/ticket/484
 http://trac.helenos.org/ticket/485

 For those that are not familiar with the tickets, the main improvements are:
 - significantly faster rendering (making qemu/non-KVM usable) if user limits
   himself just to window movement and resizing (i.e. avoiding rotation, 
 scaling
   and transparency)
 - preview of the result of window transformation is depicted by a ghost 
 frame
   following the mouse pointer
 - changing of window focus feels more natural and intuitive (mouse click 
 handler
   behaves more like in mainstream operating systems, window titles changes 
 color
   to reflect whether they have focus or not)

First of all, it is very nice and it improves the experience a lot :-).

But when trying the latest mainline (1725) I encountered a weird
problem: sometimes the window title bar is not redrawn when the window
loses focus. Screenshot is attached.

What is odd about this is that I was able to demonstrate this only
when running in QEMU without KVM with amd64 profile. With KVM, it runs
smoothly; on ia32 it is okay both with and without KVM.

Steps to reproduce (everything is done using mouse in the GUI):
1) Start default amd64 build without KVM.
2) Move the vterm to the middle of the screen
3) Click vterm on the vlaunch menu

Now, both vterm windows looks as if they have a focus, moving cursor
above the inactive one redraws the title bar a bit. Swiching to
kconsole and back fixes the colours.

Are you able to reproduce this?

I tried this on 64bit Linux 3.6, QEMU kvm-1.2.0.

Thanks
- Vojta




 If you don't have any objections, I will eventually merge the branch into
 mainline and close the tickets. Right now, I am however unable to properly 
 test
 the branch with recent mainline changes because of i8042 performance issue 
 that
 is currently being investigated by Jakub. Therefore, I will probably wait 
 until
 it is resolved. In case anybody is eager to have the GUI improvements rather
 sooner than later, and is able to test it in VirtualBox or qemu/KVM without
 the significantly lagging mouse pointer, feel free to merge it instead of me.

 Petr


 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
attachment: compositor_foreground_windows.png___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Ticket #357

[Vojtech Horky]

Hi, Kapil.

2012/11/7 Kapil Agarwal dragonslayerlord2...@gmail.com:
 On Thu, Oct 18, 2012 at 11:51 AM, Martin Decky mar...@decky.cz wrote:

 You have to use the functions from uspace/lib/c/generic/str.c to properly
 decode and encode UTF-8 strings:

 str_decode()
 str_decode_reverse()
 chr_encode()

 What should be the expected output for the functions str_decode and
 chr_encode for some input ?
 as far as i can see after executing some codes, the output is the same as
 the input in both of them
For characters available in plain 7bit ASCII (i.e. American
alphabet), the output would be the same because these characters are
encoded the same way in UTF-8.
Have you tried putting there some multibyte character - e.g. some national one?

 Also, for testing purposes, how can I input non-ASCII characters ?
Currently, there are 3 keyboard layouts available. You can switch
between them with Ctrl-F1 (US), Ctrl-F2 (Dvorak) and Ctrl-F3 (Czech).
If you want to add your own one, /uspace/srv/hid/input/layout is the
directory you are looking for.

- Vojta



 --
 Kapil

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] 70th HelenOS project meeting

[Vojtech Horky]

Hello.

2012/11/5 Jakub Jermar ja...@jermar.eu:
 The 70th meeting will take place on Saturday of November 10, shortly
 after 14:00 somewhere in Prague. Please let me know whether you plan to
 come so that I can make a reasonable reservation, no later than by
 Thursday evening. Also, do let me know whether you have any preferences
 for the venue of the meeting.

I am sorry, I will not attend this one. But I am planning to join the
hangout. See you there.

- Vojta


 Jakub

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

[HelenOS-devel] GSoC summit session notes

[Vojtech Horky]

Hello,

I am sending a few notes from GSoC mentor summit that are related to
the GSoC project itself.

Although some of the topics may sound as for mentors only, I decided
to post here. First of all, some of the topics are related to
contributing to HelenOS in general and also it might be interesting to
hear opinion from the actual participants in this and previous GSoC. I
know that some of the notes do not apply to the project of our size
(compared with huge projects such as GNOME or LibreOffice) but
maybe they can make think someone in a new direction.

The notes are in no particular order and I tried hard to compress
topics discussed on several sessions into a single block.



The GNOME project has an initiative GNOME Love [1] targeted at getting
new contributors to GNOME (or one of its thousands subprojects) and
help them with their first steps.

That has two parts. First, there are listed individual developers for
each area to contact when in need for help. Next, some bugs has
special keyword to mark them as suitable for beginners.

Personally, I like idea of marking some tickets for beginners and I
think this could work for us as well. Although new contributors do not
appear each day, they usually ask the question where do I start with
coding?. And the answer to browse open tickets is not that helpful
because the bugs does not have difficulty assigned. The priority
category really does not help because, for example, both #382 [2] and
#309 [3] are marked minor but definitely #382 is not suitable for
the first contact with the sources while #309 could be.



There were several discussion on the topic reports. This year we
(kind of) enforced weekly reports but it sometimes resulted in kind of
false sense of progress while sometimes the reports were too big to
get oriented in. We weren't the only one with similar problem.
Different projects tackled this issue differently. From asking for the
report every other week to the format write whenever there is
something (even if it meant report every other day).

Some projects required that the report should contain only three
bullets. What was done since last report, what are the plans for
following
few days and what are the problems the student is currently
experiencing. Other projects preferred reports in blog-post form (plus
they often used some script to generate table similar to ours).

Some project based the reporting on the Scrum approach and each
student described his/her progress twice a week during short telco
with his/her mentor. The sessions happened always at the same time and
were kept as brief as possible (their format was kind of similar to
the three bullet report above).



It also seems that it is encouraging for students if they know that
they would meet with their mentors and fellow students on some
conference either during GSoC or after it. Some huge project has their
own conference, some meet during general open-source conferences (such
as FOSDEM). From what I have heard it is sometimes possible to ask
Google to pay partially the traveling expenses.


That's it, I will post some notes on OS-sessions in a separate e-mail.

- Vojta

[1] https://live.gnome.org/GnomeLove
[2] http://trac.helenos.org/ticket/382
[3] http://trac.helenos.org/ticket/309

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] 69th HelenOS project meeting

[Vojtech Horky]

Hi,
I will come.
- Vojta

2012/10/8 Jakub Jermar ja...@jermar.eu:
 The next meeting will take place on Saturday of October 13, shortly
 after 14:00 somewhere in Prague. Please let me know whether you plan to
 come so that I can make a reasonable reservation, no later than by
 Thursday evening. Also, do let me know whether you have any preferences
 for the venue of the meeting.

 Jakub

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] GUI problems

[Vojtech Horky]

Hi.

2012/8/31 Jiri Svoboda jirik.svob...@seznam.cz:
 HI,

 Jakub wrote:
 Not
 sure if log_msg() is suitable for logging from the async framework.
 Perhaps klog_printf() could do.
 Several points here:
 nbsp;- log_msg() called from async framework introduces a dangerous 
 layer-reversal - lower layer - async - calls to higher level - log_msg() 
 (which depends on VFS), leading to the possibility of deadlocks
 nbsp;- I don't think libraries should log anything to system logs, in 
 general, unless the logging is explicitly enabled for debugging purposes - I 
 have this from hands-on experience in Solaris
 nbsp;- in case of libraries errors should be propagated to the caller, not 
 logged out of band and out of control of the caller
 nbsp;- log_msg cannot be currently used in libraries because it does not 
 support contexts yet. It would clash with application using the same facility
In my logging branch [1] I did some improvements to the logging that
covers the problems mentioned above. It needs some cleaning but I am
planning to merge it some time next week.

I plan to document the features in the wiki in more detail, but
briefly it allows following:
- specify different logs - e.g. it is possible that each device in a
driver would have its own log (that could be, for example, printed to
a separate file)
- the different logs allows for logging for libraries as each library
could (on initialization) create its own log and use that instead of
the default one
- create hierarchy of these logs (e.g. have separate log for each USB
pipe of a USB device)
- specify reported level for each log at runtime - e.g. print all
devman messages but only fatal errors of certain driver etc.
- specify reported level for each log at boot time via GRUB parameters

Currently, everything is logged into a file but it shall not be that
difficult to add sending the messages to a different target, such as
socket, for example.

- Vojta

[1] https://code.launchpad.net/~vojtech-horky/helenos/logging

 Cheers
 Jiri

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] udf soft deadline

[Vojtech Horky]

Hi Julia.

2012/8/15 Julia Medvedeva shante.m...@gmail.com:
 1. Clean code from test printf and old code.
Consider converting the debugging printf to HelenOS logging API [1].

There is no harm to leave the debugging prints in the code as long as
they are not printed during normal run. And they might be useful when
some improvements/fixes would be needed at a later time.

Thanks.
- Vojta

[1] http://trac.helenos.org/wiki/Logging

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Bithenge: flow control implemented

[Vojtech Horky]

Hello, Sean.

2012/8/7 Sean Bartell wingedtachik...@gmail.com:
 First, if you specify an unknown field in a switch (run with hex:00)
 transform main = struct {
   switch (.non_existent) {
   1: {  };
   else: {  };
   }
 };
 Bithenge would enter some endless recursion and eventually die.

 The problem is that in order to find .non_existent, Bithenge tries to
 figure out whether the switch generates .non_existent, which means
Do I understand it right that the switch could be driven by a value
assigned inside that switch? That would hardly make sense.

 it has to find .non_existent. I've added this to the future feature
 list, even though it's more of a bug than a feature.
I would consider the endless loop definitely a bug. Especially if an
error in the script results in a page fault.


 Do you think you can improve that somehow? Either by defining more
 fine-grained error codes or returning bigger context or ...?

 I think the solution would be to put some sort of error information in
 the bithenge_scope_t. I've also added this to the future feature list.
That would be very nice. I think that just adding a char * member to
which you could assign more descriptive messages would be enough.


 Last thing - do you think it would be possible to support recursive
 structures? At least a simple variant that a structure can reference
 itself? I am not sure that it is possible at all with current design
 but it might be a natural way of describing some data...
 What I have in mind is this:
 transform recursive = struct {
 .have_next - nonzero_boolean - uint8;
 .data - whatever;
 if (.have_next) {
 .next - recursive;
 }
 }

 Well, this case could be handled with do...while:
Yes. As a matter of fact, my example was a simplified workaround for
not having the possibility to use fields as inputs to another
transform.

 Other cases would still need recursion, and it wouldn't be too hard to
 implement, so I've added it to the future feature list.
I agree. But it is definitely not a high-priority issue.

Thanks.
- Vojta


 Thanks,
 Sean

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Bithenge: bitfields and expressions

[Vojtech Horky]

Hello, Sean.

2012/8/8 Sean Bartell wingedtachik...@gmail.com:
 Hello, everyone,

 I've implemented bitfields and more advanced expressions in Bithenge.
 Bitfields are handled by making bit blobs, which behave just like byte
 blobs; the main point of interest is the new built-in transforms that
 work with bit blobs[0]. Expressions now support addition, subtraction,
 and multiplication, and they can be used as transforms themselves[1].
Nice. Especially [1] makes it much more usable on real-world formats. Thanks.

Just one comment - do not forget to test your implementation under
HelenOS. Rev. 1560 would not compile due to some maybe uninitialized
warning. (It might be caused that you have slightly different version
of the toolchain.)

 Tomorrow, I will implement the ability for scripts to get subblobs.
 I plan to support the syntax blob[start,length] and blob[start:end].
 With the new expression support, a basic implementation of subblobs
 should be fairly quick, so I will also start working on a basic FAT
 script tomorrow to demonstrate Bithenge.
Good. Looking forward to the FAT script.

With the last bunch of features, I was able to finish my GIF script.
Because I plan to play with BitHenge even more next week, I started my
own branch at [2]. It contains the GIF script and several testing
images - the smallest GIF image possible, an animated GIF and also
HelenOS logo.

 I also plan to implement a basic C code generator, as discussed
 previously, and possibly trivial editing support before the end of GSoC
Okay. Sounds reasonable.

 if time permits. However, the soft deadline is next Monday, and I will
 stop coding then to focus on documentation and testing. I have no
 immediate time commitments after GSoC ends, and I want to start work on
 the other major features I didn't manage to reach during the summer
 (DWARF support, an interactive browser, and constraint-based decoding).
That would be nice.

Thanks.
- Vojta

[2] https://code.launchpad.net/~vojtech-horky/helenos/bithenge


 Thanks,
 Sean Bartell

 [0] http://trac.helenos.org/wiki/StructuredBinaryData#Builtintransforms
 [1] http://trac.helenos.org/wiki/StructuredBinaryData#Expressions

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Bithenge: flow control implemented

[Vojtech Horky]

Hello, Sean.

2012/8/4 Sean Bartell wingedtachik...@gmail.com:
 Hello, everyone,

 I've implemented conditions and repetition in Bithenge[0]. There are
 more examples in the test files[1].
I have two more comments and one question.

First, if you specify an unknown field in a switch (run with hex:00)
transform main = struct {
switch (.non_existent) {
1: {  };
else: {  };
}
};
Bithenge would enter some endless recursion and eventually die.

Next, I have a suggestion on error reporting. Right now, any error is
reported via its number only. If you have an error in your script
(logical, not syntactical), printing stops somewhere in the middle
with invalid value or similar, giving almost no hint what is the
root cause.
Do you think you can improve that somehow? Either by defining more
fine-grained error codes or returning bigger context or ...?

Last thing - do you think it would be possible to support recursive
structures? At least a simple variant that a structure can reference
itself? I am not sure that it is possible at all with current design
but it might be a natural way of describing some data...
What I have in mind is this:
transform recursive = struct {
.have_next - nonzero_boolean - uint8;
.data - whatever;
if (.have_next) {
.next - recursive;
}
}


Thanks
- Vojta


 My next task is to implement bitfields. Decoding a sequence of bits is
 similar to decoding a sequence of bytes, so I will reuse the existing
 code and syntax as much as possible. I'm still two days late, partly
 because repetitions required more thought than I expected, but I'm still
 hoping to catch up.

 Thanks,
 Sean Bartell

 [0] http://trac.helenos.org/wiki/StructuredBinaryData#FlowControl
 [1]
 https://bazaar.launchpad.net/~wtachi/helenos/bithenge/files/head:/uspace/dist/src/bithenge/

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Bithenge: parameters implemented

[Vojtech Horky]

Hello, Sean.

2012/8/2 Sean Bartell wingedtachik...@gmail.com:
 Now, concretely: in parse_if, you jump into a conditional block. I
 would consider that a very bad practice and actually I am surprised
 that such jump does not produce any warning. Better is to go with the
 common practice and put the error block at the end of the function.

 Well, the whole purpose of goto is to interfere with the control flow.
 It could be confusing, though, so I fixed it by moving some code to a
 separate function.
Thanks. I agree, my point was about not creating surprises.


 I have a general principle that functions like bithenge_if_transform()
 and bithenge_const_expression() should reliably free their arguments,
 even if an error occurs. I've added an explanation to the wiki page[0].
Aha. I should have read the code more carefully.

Btw, I started writing script for BMP images. It needs repetitions to
be applicable to arbitrary file but with hard-coded values I am able
to completely decode simple images.

Bye
- Vojta


 bithenge_if_transform() follows this principle and does not leak, even
 on error (I checked with Valgrind). However, I forgot to free the node
 in bithenge_const_expression() when an error occurs, so it was a leak.
 Thanks for pointing this out.

 Thanks,
 Sean

 [0] http://trac.helenos.org/wiki/StructuredBinaryData#UsingtheAPI

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Bithenge: parameters implemented

[Vojtech Horky]

Hello, Sean.

2012/7/30 Sean Bartell wingedtachik...@gmail.com:
  However, many cases are not yet possible; for instance, USB descriptors
  can't use the length field because it includes its own length. This will
  be possible once scripts can get arbitrary subblobs.
 I am not sure I follow. I thought that these subblobs would be useful
 when the data contains some kind of pointers in them (e.g. that actual
 data are at given offset). But here you have a bit different
 situation, IMHO. If the descriptor is of unknown type (e.g. some
 vendor specific), you want to skip next (.bLength - 2) bytes and
 decode next descriptor. (Obviously, if you know the descriptor type,
 you ignore the .bLength field.) I do not see how subblobs would help
 you. What have I missed?

 First, when you know the descriptor type, I would still use the length
 field to get the right amount of data and then decode it. Your way is
 essentially equivalent, though. Second, I'm hoping to make all sorts of
 seeking possible with subblobs, so you could say read a uint32le into
 .len, then go back and read .len raw bytes to skip the unknown
 descriptor.
Thanks for the explanation. Makes sense to me now.

 I implemented if today, but documentation, examples, and switch will
 have to wait for tomorrow.
The functionality side is okay. I played with it a bit and it works fine.

However, you are still behind your (revised) schedule. And the amount
of commits (code) does not indicate any increased effort. At least
that is the way it looks to me...


During last days I also did a quick review of your new code and I have
a few comments.

In general, the code looks clean and tidy. Also, you are consistent
and the code is well structured.

Now, concretely: in parse_if, you jump into a conditional block. I
would consider that a very bad practice and actually I am surprised
that such jump does not produce any warning. Better is to go with the
common practice and put the error block at the end of the function.

In the same function, it looks to me that there is a leak in case
bithenge_if_transform() fails.

Another leak is in parse_expression() - if the
bithenge_const_expression() fails, you do not destroy the previously
created node.


Bye,
- Vojta



 Thanks,
 Sean

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Bithenge: parameters implemented

[Vojtech Horky]

Hi Sean.

2012/7/29 Sean Bartell wingedtachik...@gmail.com:
 Hello, everyone,

 I've finished implementing parameters in Bithenge. You can see the
 possibilities in the new example file[0]. Parameters make it possible to
Good job. I have tried it and it works :-). Though I was confused a
bit where the .len (in pascal_string) came from. In my opinion, the
original version of the file [1] was more intuitive. On the other
hand, it shows that Bithenge supports nesting. Very nice.

 handle fields of known length as well as length fields followed by data.
 However, many cases are not yet possible; for instance, USB descriptors
 can't use the length field because it includes its own length. This will
 be possible once scripts can get arbitrary subblobs.
I am not sure I follow. I thought that these subblobs would be useful
when the data contains some kind of pointers in them (e.g. that actual
data are at given offset). But here you have a bit different
situation, IMHO. If the descriptor is of unknown type (e.g. some
vendor specific), you want to skip next (.bLength - 2) bytes and
decode next descriptor. (Obviously, if you know the descriptor type,
you ignore the .bLength field.) I do not see how subblobs would help
you. What have I missed?

 I'm currently one day behind schedule; hopefully, I'll be able to make
 it up later. My next task is to implement conditions (if and switch).

Thanks for the report.

- Vojta

[1] 
http://bazaar.launchpad.net/~wtachi/helenos/bithenge/view/1537/uspace/dist/src/bithenge/test.bh

 Thanks,
 Sean Bartell

 [0] 
 https://bazaar.launchpad.net/~wtachi/helenos/bithenge/view/head:/uspace/dist/src/bithenge/test.bh

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

 Thanks,
 Sean Bartell

 [0] 
 https://bazaar.launchpad.net/~wtachi/helenos/bithenge/view/head:/uspace/dist/src/bithenge/test.bh

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Bithenge: new plans

[Vojtech Horky]

Hello Sean.

2012/7/22 Sean Bartell wingedtachik...@gmail.com:
 Hello, everyone,

 I returned from vacation this week, but I started working slowly due to
 illness. I was too busy to work much during my vacation, but I designed
I hope you are okay by now.

 the syntax for transform parameters[0].
The syntax looks nice and clean.

 I've also worked on planning the rest of the summer. My original plan
 was to finish the language by the start of my vacation. Unfortunately, I
 only completed the basic parts of the language. My suggested new plan is
 to continue developing the language as follows:

 Jul 21-22: implement some minor improvements such as indentation
 support.

 Jul 22-27: implement transform parameters and some transforms that use
 them.

 Jul 28-29: implement conditions (if and switch) and possibly comparison
 operators.

 Jul 30-Aug 1: implement basic repetition. There will be three types:
 - apply a transform repeatedly until the end of the data.
 - apply a transform a known number of times.
 - apply a transform until some condition is true, if the last element is
   specially marked somehow.

 Aug 2-4: implement bitfields. It should be possible to specify that some
 sequence of bytes should be treated as a sequence of bits, and to read
 arbitrary-length bitfields like with structs.

 Aug 4-6: allow scripts to get arbitrary subblobs. This is necessary when
 the data has pointers to other offsets in the data, rather than all
 being stored sequentially.
Thanks for the schedule. I hope you would be able to follow it and
deliver all the promised features.

As it looks there would be new features every few days, you can make
(and I would recommend it) your status reports more often. No need to
wait till the end of the week. I am looking forward to try them.

 This schedule leaves 6 more days until the suggested end of coding, and
 there are 7 days after that until the deadline. There are several things
 I could work on during that time:

 - An interactive browser for the decoding result. Instead of just
   dumping the result as JSON or a Python literal, you could start the
   browser and use familiar commands like ls, cat, and find to explore
   the decoded tree. This would only take a few days.
Although I originally wanted the browser, now I would rather vote for
other things. We can always scroll through the dump in the editor. Or
finally implement the pipe FS and a proper pager ;-).

 - A program to generate C code from Bithenge scripts. Given a Bithenge
   script describing a structure, you could automatically generate a
   standalone C header and code to read that structure and do the
   endianness conversion, offset calculation, and so on. The output could
   be used in HelenOS instead of writing the code manually. I estimate I
   could make this in a few days for basic structures, with more time
   needed for repetition support.

 - Trivial editing support. It would be possible to change the values of
   data fields as long as you didn't change their lengths. This would
   probably take 2-4 days. Figuring out how to do more complex editing is
   an open-ended task that could take weeks.
I would like to have an API to change (simple) fields. More complex
editing is probably out of question. I also think that it is not
necessary to add write support for all backends.

 - DWARF support. Bithenge could read the DWARF debugging information
   from an ELF executable and convert it into a Bithenge script, which
   could then be applied to a core dump or running task memory to view
   the task's data structures. The DWARF specification is fairly complex,
   and I don't know how much of it is necessary for a basic
   implementation, so I think this could take anywhere from 1-4 weeks.
Given the fact that you cannot predict how long it would take, it
would definitely take longer and we probably need to drop this part.
Though I am not very happy about it.

 - A complete FAT script. Although the language improvements above should
   be enough for useful FAT decoding, there will be more potential
   language improvements. For instance, with some advanced language
   features Bithenge could automatically decode long file name entries
   and associate them with the correct file. This idea involves extending
   Bithenge to implement some chosen format, like FAT, as well as
   possible, and I could spend an arbitrary amount of time on it.
Having Bithenge script of a complex data structure (such as FAT) is a
must-have part of your GSoC project.

 I'm interested in working on all of these at some point, but I'd like
 your opinions on what I should do during GSoC.
The FAT script (or something similarly complex) must be delivered
during GSoC. Next I would like to see the code generator and trivial
editing support.

Also do not forget about the documentation. I appreciate that you
document all public functions, but there ought to be some kind of
higher-level documentation as well. For example in the form of short

Re: [HelenOS-devel] Unexpected behaviour of memalign()

[Vojtech Horky]

Hi Jiri.

2012/7/20 Jiří Zárevúcky zarevucky.j...@gmail.com:
 I have one comment/question. I have tried the memalign test from the
 #395 [1] and it works. But: I have run it in Qemu (ia32 build) and if
 the RAM is 33MB it produces quite unexpected output - it is possible
 to allocate bigger chunk of aligned memory than of unaligned. I.e.,
 memalign() succeeds where malloc() fails for the same size.


 Is it possible that you used the function as written in the ticket,
 i.e. memalign(1  i, 32)?
You are a right. Sorry for the fuss, I should have read the code more carefully.

 That call has a wrong order of arguments. Alignment should be first.
 I suspect that would explain the difference.
After thinking more about why I wrote the test that way, the ordering
is correct. The idea was to test various alignments and malloc() was
used only to test how much memory is available.

Thanks and sorry again.

- Vojta



 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Unexpected behaviour of memalign()

[Vojtech Horky]

Hi Jiri!

2012/7/20 Jiří Zárevúcky zarevucky.j...@gmail.com:
 On 20 July 2012 16:55, Jiří Zárevúcky zarevucky.j...@gmail.com wrote:
 On 20 July 2012 16:36, Jakub Jermar ja...@jermar.eu wrote:

 In your patch, why don't you simply add size and align in area_grow(),
 just as you do for the new areas?


 I wanted to avoid requesting more pages than necessary, but now that I
 think about it, it probably doesn't really matter, does it?
 What I find peculiar though is that growing the area always creates a
 new free block, even if the previous block is free.
 Seems to me like a completely unnecessary fragmentation.

 There, my final iteration.
I have one comment/question. I have tried the memalign test from the
#395 [1] and it works. But: I have run it in Qemu (ia32 build) and if
the RAM is 33MB it produces quite unexpected output - it is possible
to allocate bigger chunk of aligned memory than of unaligned. I.e.,
memalign() succeeds where malloc() fails for the same size.

I admit I haven't investigated this in more detail (what is the exact
difference where this phenomenon occurs) but maybe you would be able
to answer right away. Do you think that is an expected behaviour of
your implementation or it indicates some subtle problem?

Thanks!

- Vojta

[1] http://trac.helenos.org/ticket/395

 I went back to just adding the alignment size regardless of whether
 it's necessary. Shouldn't matter much.
 What I kept is allocation directly after grow, and I modified
 area_grow() to append to the last block if possible.
 Feel free to ignore that last part if you wish, it just seemed to me
 like the right thing to do there.

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Re: [HelenOS-devel] Bithenge: first commit

[Vojtech Horky]

Hello Sean.

2012/5/25 Sean Bartell wingedtachik...@gmail.com:
 Hello, Vojtech,

 On Thu, May 24, 2012 at 11:24:37AM +0200, Vojtech Horky wrote:
 2012/5/24 Sean Bartell wingedtachik...@gmail.com:
 I have a few comments (mostly details).

 First of all, I am not able to compile the code for 32bit architecture
 ...
 blob.c:71:2: note: expected 'aoff64_t *' but argument is of type 'size_t *'

 When writing functions, the opening brace shall be on next line and
 when the parameters do not fit on a single line, they are indented
 with 4 spaces instead of two tabs.

 In the bithenge/Makefile, feel free to change the author to yourself ;-).

 In block.h, I would recommend to use #include loc.h instead of
 loc.h to emphasize the fact that you are including a library header
 instead of a local one.

 If you are calling malloc() or realloc() and they fail, return ENOMEM.
 Our implementation of malloc() does not set errno.

 All fixed.
Simply great :-). Thank you.


 I like the way you are hiding the details when working with block
 device but I think it would be better to hide more the direct
 typecasting:
 block_blob_t *blob = (block_blob_t *)base;
 with something like
 block_blob_t *blob = BLOCK_FROM_BLOB(base);
 to ensure smoother change if (for whatever reason) you would have to
 move base from the beginning of the structure.

 I'm not sure why I would need to do that, but okay. I used static inline
 functions instead of macros for cleanliness.
Well, me neither ;-). I just think that it is safer that way with
respect to some further changes. Anyway, it was rather a suggestion
than anything else.

 
  I have also decided on the data structure the library will represent.
  Primitive values will be binary blobs, integers, or Unicode strings.
 I am not sure that is enough. At least, you have to have a way to
 distinguish integers of various sizes, signness and endianess.

 The tree only contains the final result of decoding the binary data. The
 converter (which is the part I'm still thinking about) may know that
 some data is a 4-byte little-endian unsigned integer, but after it's
 decoded it's represented in the tree just like any other integer.
Ahaaa. Do I get it right, that the node would be something like a union {
long number;
char *utf8_string;
uint8_t binary;
} ?
Or am I still on a different planet?


  The data structure will be a tree; each edge will be labelled with a
  primitive value, and each leaf node will store a single primitive value.
 And inner node would be...?

 It only has edges to other nodes. An example tree for a FAT filesystem
 could look like this, where 'O' represents an internal node and
 fat, 0, 0xfff0, ... are primitive values:
I see. Thanks. I am looking forward to see the API for traversing and
accessing this.

- Vojta


  O
  |
  +---fat--O
  |         +---0---0xfff0
  |         +---1---0x
  |         +---2---0x
  |
  +---root--O
            +---0---O
            |        +---name---README.TXT
            |        +---size---0x1351
            |
            +---1---O
                     +---name---KERNEL.ELF
                     +---size---0x38e9a2

  Each node is responsible for allocating and freeing its children. It may
  be necessary later to add reference counting or use a DAG instead of a
  tree, but I will start with this simple model.
 
  I have some ideas for the design of format specifications, but I still
  need to spend more time thinking them through. I will write a minimal
  demo program in Python to determine whether they are viable.
 I hope you will share it with us :-).

 Thanks,
 Sean Bartell

 ___
 HelenOS-devel mailing list
 HelenOS-devel@lists.modry.cz
 http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel