swhipple · HackerTrans

swhipple

no profile record

comments

9 anni fadiscuss

This has been available for contributors in the United States for some years now, and I've used it to sign the assignment documents in the past. It might not be available in all countries though.

> If you use GPG, you can sign your assignment using a detached signature in the following manner:

> gpg -a --detach-sig ASSIGNMENT

> Where ASSIGNMENT is the PDF file(s) as you have received it from us.

> Then simply email the assignment, key ID, and signature file back to us at [email protected]. Please make sure that your key is listed on a public keyserver.

9 anni fadiscuss

The mkstemp you are seeing is probably the one from gnulib. A lot of GNU software uses their own versions if they detect the platform one is broken; it may be incorrectly replacing it in this case.

https://www.gnu.org/software/gnulib/manual/html_node/mkstemp...

https://github.com/emacs-mirror/emacs/blob/65eee8392ff95f58f...

9 anni fadiscuss

The EPL is roughly in the middle of MPL and LGPL in terms of copyleft scope. MPL requires per-'file' source sharing. EPL requires per-'module' source sharing. LGPL requires per-'module' source sharing and separating the module to permit the user to use/replace it without additional restrictions.

The one downside that EPL has is that, unlike MPL (without "Incompatible With Secondary Licenses" notice) or LGPL, it is incompatible with the GPL-family of licenses. It specifies different conditions for providing the source code and has a governing law clause (New York).

It is popular in the Java ecosystem (Eclipse, Clojure, etc).

9 anni fadiscuss

The difference is that attempting to add code to a live system that mishandled an input (either from a non-upgraded node or an upgraded one) would result in a type-error and reject the upgrade.

You could still use Erlang's crashing and supervisor technique, but you would have the additional benefit of using static typing across a distributed system (where each node may or may not have received the upgrade yet).

9 anni fadiscuss

The main problem with pushing a typechecked live-upgrade in one shot is that you'll need to put a big lock around the distributed system (A non-upgraded node messaging an upgraded one would be fine, because the upgraded one knows the conversion function, but what happens in reverse scenario?)

It could be done without a big lock by splitting into three steps:

1) Push an upgrade that changes the types and adds the conversion functions. The valid type is the union of the old type and the new type. Wait until all nodes complete the upgrade.

2) Push an upgrade that instructs the nodes to convert their data and start using the new types by default. Wait until all nodes complete the upgrade.

3) Push an upgrade that removes the old types and conversion functions.

9 anni fadiscuss

> As I said, name me a format that I can't parse correctly as a Python one-liner.

mboxo? [1] It is a popular text format that cannot be unambiguously parsed.

More generally, most Unix tools' output is also not able to be unambiguously parsed. For example, use gcc to compile a file, then collect the warnings? The regex "^.+:\d+:\d+: warning.*" will be right most of the time, but there's no 'correct' way to parse gcc output (there is not a surjective mapping of output to input).

There are various ways to work around the problem: mboxrd format uses an escape sequence to work around the earlier problem mentioned with mboxo. `ls -l --dired' (GNU) will allow you to parse ls by appending filename byte offsets to the output. `wc --libxo xml` (FreeBSD) will give the output in XML, which is unambiguous as well. multipart/form-data (RFC2388) is used to embed binary data in a text format, by using a byte sequence which doesn't appear in the data.

Binary formats present their own set of issues, but "accidentally unparseable" is more common in text-based formats (or ad-hoc text output).

[1] https://jdebp.eu/FGA/mail-mbox-formats.html

9 anni fadiscuss

See here [1], under "Why make this change?".

[1] https://www.nczonline.net/blog/2016/10/the-ecmascript-2016-c...

9 anni fadiscuss

I don't quite understand the real world use-case Veriexec is designed to solve.

1) Prevent tampering by making part of the system immutable? The fingerprint isn't necessary; unconditionally prevent modification to the relevant files instead.

2) Prevent tampering by using trusted files? Normally this should be done by having a set of trusted keys, not hardcoded hashes. That way you can still securely upgrade the system.

3) Accessing files from a remote untrusted filesystem? This doesn't seem to work either; see the caveats section in veriexec(9).

Am I missing something here?

9 anni fadiscuss

> In HTML, <tag/> and <tag></tag> are equivalent

In HTML, <script></script> is valid. <script /> is invalid. <br /> is valid. <br></br> is invalid. So they are represented differently.

> Using (:tag/) is a bad idea because that would screw up attributes.

For my example?

    ((:tag/ :attr "value"))               => <tag attr="value" />
    ((:tag  :attr "value") "..." (:/tag)) => <tag attr="value">...</tag>

> You actually can distinguish between those if you really want to. It's just a matter of picking a convention.

That sounds like it could work. So a leading `nil' would be treated as a special case (not a child node):

    (:pre "
      " (:span "one
      ") "
      " (:br) "
      " (:span "two") "
      " (:br nil) "
    ")

9 anni fadiscuss

It was <br> and <br /> for my example (</br> isn't a valid tag). The point that I was getting at was that <br> and <br /> self-closing tag are represented differently (<tag>, <tag />, and <tag></tag> are all different) in a parsed SGML data structure (though they both are equivalent in the HTML DOM tree in the browser).

This is why you would need separate tags to emit them properly with an S-expr syntax (tag), (tag/), and (tag)(/tag) in my example.

9 anni fadiscuss

> HTML is a string of characters (syntax). The DOM is a data structure (semantics). [...] S-expressions are a data structure, different from the DOM, but S-expression syntax is a syntax.

I believe this is where the confusion is coming from. When you parse HTML syntax, you get a data structure; this is the same as when you read sexpr syntax, you also get a data structure. Both these data structures are different from the DOM tree.

Try this example:

    <pre>
      <span>one
      </span>
      <br>
      <span>two</span>
      <br />
    </pre>

Can CL-WHO generate HTML that matches that? (i.e. feed both into a tool like BeautifulSoup and produce the same data structure?)

Outside of CL-WHO and Hiccup-type libraries, you can of course use S-exprs to represent the same data structure. Here's a hypothetical S-expr syntax that might produce the same data structure:

    ((pre)
      "\n  " (span) "one\n  " (/span)
      "\n  " (br)
      "\n  " (span) "two" (/span)
      "\n  " (br/) "\n"
     (/pre))

Which is what I believe JimDabell meant by:

> you can't represent all valid HTML documents as S-expressions, at least not in the convenient way people assume

9 anni fadiscuss

There's currently a feature freeze and plan to switch to WebExtension after the necessary APIs are added to Firefox: https://github.com/akhodakivskiy/VimFx/issues/860

10 anni fadiscuss

That's interesting -- I was wondering in which cases typedef changes the parse tree, and came across a few [1]:

    a (b);      /* function call or declaration */
    a * b;      /* multiplication or declaration */
    f((a) * b); /* multiplication or deref and cast */

> With one further change, namely deleting the production typedef-name: identifier and making typedef-name a terminal symbol, this grammar is acceptable to the YACC parser-generator.

[1] http://eli.thegreenplace.net/2007/11/24/the-context-sensitiv...

10 anni fadiscuss

I think there are two separate issues here: unbounded queues vs finite resources and also the overhead of asynchronous message passing (or "don't make every particle its own actor").

Regarding applying backpressure, you're correct that Erlang doesn't have a silver bullet. Process mailboxes are unbounded and can exhaust resources. Or you can implement a buffer and drop messages based on some strategy.

As for making every 'operation' asynchronous, you could do it and not run into any additional unbounded queue or error handling problems, but it would add overhead without any advantage over concurrency via preemption.

10 anni fadiscuss

I think this may be the report [1]? It seems that their P1 did not meet the standards, due to miscommunication -- not language incapability, but they were able to correct it in P2:

> It happened that some modifications and extensions to Reference 1 were agreed to at the experiment kickoff meeting at NSWC. Dr. Jones and Dr. Hudak were not informed of those extensions until after the completion and review of the initial draft of Prototype 1. [...]

> Prototype 2: We believe that our Prototype 2 will be most comparable to the prototypes prepared by the other teams. This prototype satisfies all mandatory requirements of the problem as defined in References 1 and 2, and also incorporates generalizations to support anticipated future requirements. To accomplish this task, the original author of Prototype 1 made a number of modifications and enhancements requiring about five hours [...]

P1 and P3 solutions are attached in appendices, along with some others.

[1] http://www.cs.yale.edu/publications/techreports/tr1031.pdf

10 anni fadiscuss

One Emacs Lisp aspect that I enjoy for interactive configuration is the lack of packages. When interactive programming with some other languages, there's some cognitive overhead "which package am I in?" depending on how you use the user/repl packages and scratch buffers. Without packages, everything is unambiguous and avoids the issue entirely.

re: dynamic scope, I agree that Emacs' future is with lexical-binding for non-special variables. Chris Wellons recently wrote a great post which has shown up on my radar: http://nullprogram.com/blog/2016/12/22/

10 anni fadiscuss

I agree that freedom and practicality are related, but disagree that it undermines the argument. If they were completely unrelated, source code availability would not be an issue; however the legal and practical freedom to do something is often not zero effort or little work.

I'm wondering what you have in mind by user-modifiable systems. For example, KDE and Firefox are free and allow for quite a bit of user-customization without any programming knowledge. At some level you would naturally have to write code.

I recently came across this interview and thought it was well done. Stallman responded to a similar question: https://youtu.be/NB8mCcLRxlg?t=59m55s

10 anni fadiscuss

To add on to your point, this is called the 'paradox of freedom' -- that you cannot have both unlimited freedom and ensure freedom for the future. At the end of WWII, Karl Popper defended state interventionism with an argument citing the paradox of tolerance [1], and claimed ensuring a tolerant society in the name of tolerance, even when paradoxically intolerant. A parallel argument can be made in Stallman's case for copyleft to be claimed in the name of freedom.

It's also worth noting that it is not only Stallman's FSF that uses this definition w.r.t intellectual property nowadays. Lessig's CC adopted the same terminology for their share-alike license (-SA), which has the goal of preserving freedom, while -NC or -ND are considered non-free because they contain restrictions not related to this purpose. The same is true in the greater free-culture community and academic contexts from my experience.

[1] http://www.goodreads.com/quotes/25998

10 anni fadiscuss

That is true, but somewhat alleviated by Emacs' choice to indent the THEN form at a different level than [ELSE]*. A novice would notice that the code looks incorrect as they were typing it.

10 anni fadiscuss

They're both appeal to nature arguments. "Tobacco should never be regulated because it grows in nature" and "Cryptography should never be regulated because it uses math".

There are plenty of reasons to be anti-DRM or pro-user privacy, but the "it uses numbers" argument is not a particularly good one.