Recent Forum Posts
From categories:
page 1123...next »
Andrew Pennebaker (guest) 13 Dec 2018 16:29
in discussion Hidden / Per page discussions » Why should I have written ZeroMQ in C, not C++ (part I)

I agree that half-initialized objects are bad. I think in Java world, coders tend to accomplish this more safely using the builder pattern, which is why we get all these boilerplate FactoryFactoryFactory classes. Do C++ programmers sometimes use builder patterns? Can an entire class be marked as private/internal?

by Andrew Pennebaker (guest), 13 Dec 2018 16:29

They all sound like very weak arguments.

tons of bitching against exception to simply admit that you can use C++ without exception and still live happily (which is what most embedded software devs in C++ do).

It's totally possible to write C++ code without undefined behaviors.

Same for the whole discussion about cleanup, constructor, destructors and so forth.
As a small example, even when destructors can't be used for cleanup, they can still be very useful to detect that proper/explicit cleanup had happened.
There's no way to mimick that in plain C without language support.

So in the end you could use a subset of C++, cherry picking what makes sense for your code base and leave out what doesn't, and still you'll be better off that stupidly giving up the advantages over C.

There are only 2 valid arguments for using C instead of C++:
1) you only have a C compiler
2) you don't know C++ (Linus Torvald's real argument)

by Maurizio (guest), 13 Dec 2018 13:03

You can still return a structure in C if you want more detailed errors. For instance when parsing a file, it is useful to have a line attached to the error message :

struct foo { char *error; int line; };

Granted, the syntax is not as pretty as go but it is not that bad. I use this pattern in my code here and there and it works well while still having a readable code.

by s0laster (guest), 13 Dec 2018 11:01

Not that it's relavant anymore but I think rust would have been a good fit.

by Yep Nop (guest), 13 Dec 2018 07:08

Martin, would you considering releasing the implementations as a separate utility library ?

by Guache (guest), 13 Dec 2018 01:39

I have no experience there, sorry. It's up to you :)

by martin_sustrikmartin_sustrik, 23 Nov 2018 07:05
M R (guest) 22 Nov 2018 14:02
in discussion Hidden / Per page discussions » Two Approaches to Structured Concurrency

For ARM I mean both - running with ARM instruction set and without full libc. I think adding ASM stubs for ARM should be fairly easy, but I'm not sure how to emulate file descriptors and polling/multiplexing mechanism. Another solution would be to port it to FreeRTOS.

by M R (guest), 22 Nov 2018 14:02
Martin Sustrik (guest) 12 Nov 2018 21:42
in discussion Hidden / Per page discussions » Two Approaches to Structured Concurrency

As for the embedded ARM thing, do you mean supporting ARM instruction set, or rather running without full libc support?

As for the Erlang, I think the problem is much easier there as the language is stateless. In C on the other hand, you have to care about consistency, clean up etc.

by Martin Sustrik (guest), 12 Nov 2018 21:42
M R (guest) 12 Nov 2018 08:44
in discussion Hidden / Per page discussions » Two Approaches to Structured Concurrency

I really like the libdill/libmill idea and would like to know two things:
- have you considered porting libdill to embedded ARM (Cortex-M3-M7)?
- do you know Erlang's approach to starting/cancellation problem (http://erlang.org/doc/design_principles/sup_princ.html)

by M R (guest), 12 Nov 2018 08:44

Dunno. I have a kid so I am not super flexible. I was considering attending FOSSDEM in Feb though.

by martin_sustrikmartin_sustrik, 02 Nov 2018 13:39
Martin Sustrik (guest) 01 Nov 2018 13:55
in discussion Hidden / Per page discussions » The Eb

Yes, but I used the fact that very little is know of them to create a kind of Borgesian mystification.

by Martin Sustrik (guest), 01 Nov 2018 13:55
Nathaniel J. Smith (guest) 31 Oct 2018 23:36
in discussion Hidden / Per page discussions » Update on Structured Concurrency

But I would love to not have to deal with explicit cancel scopes at all.

Not sure how that could be possible… in Trio, there are exactly two places where you deal with explicit cancel scopes:

  • When delimiting the boundaries of the operation that you might want to cancel ("what")
  • When calling cancel() or manipulating timeouts ("when:)

Both of these kind of have to be explicit! The library can't magically guess what you want to cancel or when.

It's true that you could combine cancel scopes and nursery blocks into a single primitive that does both roles, but I think this would be a bit awkward and non-orthogonal.

We should get together during some conference to discuss it.

I wonder if there are any conferences we all go to… maybe we need to organize a structured concurrency workshop at one!

by Nathaniel J. Smith (guest), 31 Oct 2018 23:36
aausch (guest) 31 Oct 2018 20:05
in discussion Hidden / Per page discussions » The Eb

The Eb are https://en.wikipedia.org/wiki/Hephthalite_Empire?

by aausch (guest), 31 Oct 2018 20:05
Martin Sustrik (guest) 30 Oct 2018 19:09
in discussion Hidden / Per page discussions » Unikernels: No Longer an Academic Exercise

No, nanomsg is now developed by Garrett D'Amore.

by Martin Sustrik (guest), 30 Oct 2018 19:09
yuyang (guest) 30 Oct 2018 16:04
in discussion Hidden / Per page discussions » Unikernels: No Longer an Academic Exercise

Are you still working on nanomsg? What's nanomsg's final goal?

by yuyang (guest), 30 Oct 2018 16:04
Apostolis (guest) 24 Oct 2018 06:05
in discussion Hidden / Per page discussions » Unikernels: No Longer an Academic Exercise

You hooked me up on unikernels a while ago with a tweet of yours on the subject.

Now, I am looking at using the Agda programming language to write mirage unikernels, in order to use Temporal Logic of Actions and prove temporal properties of distributed systems of unikernels.

by Apostolis (guest), 24 Oct 2018 06:05
James LL (guest) 24 Oct 2018 03:56
in discussion Hidden / Per page discussions » Unikernels: No Longer an Academic Exercise

the Exokernel presented an interface for sharing block access safely to userspace 20+ years ago.

The exokernel's "library OS" approach to having each process be its own OS was an explicit inspiration for unikernels. Unikernels as Processes is the Exokernel come full circle again.

honestly a bit shocking this got published without at least citing such foundational related work. the better critique is what have they done that goes beyond it, if anything.

by James LL (guest), 24 Oct 2018 03:56
Brent (guest) 23 Oct 2018 23:29
in discussion Hidden / Per page discussions » Unikernels: No Longer an Academic Exercise

This supports JVM and golang among other languages, with huge performance gains demonstrated

http://www.vorteil.io/#downloads

by Brent (guest), 23 Oct 2018 23:29
fly (guest) 23 Oct 2018 19:39
in discussion Hidden / Per page discussions » Unikernels: No Longer an Academic Exercise

You don't need to give raw disk access to the entire block device. You can give it access to a disk image. That's no different from any other VM in that regard.

Worth noting there's also a set of ready-made packages for rumprun for the lazy https://github.com/rumpkernel/rumprun-packages

by fly (guest), 23 Oct 2018 19:39
jrain (guest) 23 Oct 2018 19:32
in discussion Hidden / Per page discussions » Unikernels: No Longer an Academic Exercise

GENODE OS FRAMEWORK http://genode.org is a system in development for over a decade now that is quite compatible with unikernel applications. the biggest challenge to adapting existing system design to a unikernel with hyper visor approach is that the user environment requires rich, deeply integrated interaction on multiple levels to make user environment paradigms useful, and emulating/implementing this in a secure setup where everything has been abstracted to interfaces is somewhat difficult and requires a lot of work. just a thiufht

by jrain (guest), 23 Oct 2018 19:32
page 1123...next »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License