eriknstr

Personally I use prototype definition without argument names because when I change the name of an argument in the C file I don't have to go to the header file and change the prototype. The code I work with in C is generally small enough that I have all the relevant C files open in different windows while working on the code, and furthermore because my programs are quite small I don't use autocompletion. What I do have however is simple completion that is not sensitive to the context but which will complete a word once I've typed part of it. This way I can have meaningful names for things without having to spend too much time when I write them.

>It's one thing to "know" how to balance a binary tree because you've read up on and practiced the most common challenges - it's something else entirely to actually think through and understand a problem, then come up with a solution.

There are too many things to know in the world in order to be able to know them all as deeply as we wish. For the things that we can get away with knowing the most common aspects of, time might be better spent elsewhere than to learn more about that thing.

I inquired about the license for that one but unfortunately they can't allow commercial use.

https://github.com/luanfujun/deep-photo-styletransfer/issues...

Current title: Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks

Current link: https://junyanz.github.io/CycleGAN/

Previous title: Berkeley's software turns paintings into photos, horses into zebras, and more

Previous link: https://github.com/junyanz/CycleGAN/

The previous title, which was based on the repo description of the previous link, was much more informative to me.

Speaking of German technical jargon, one thing that bothered me probably more than it should have was that in my Norwegian-German wordbook, "computer" ("datamaskin" in Norwegian) was translated as "festplatte". Obviously "festplatte" would mean "harddrive", not "computer".

"The cost of freedom is eternal vigilance."

In the US, the idea of freedom is valued highly. I am not from the US, and I don't live there, but I agree with them that freedom is worth fighting for.

Much of the government in both the US and many other countries are becoming more authoritarian with new technology allowing them greater possibilities of surveillance, even though there isn't a dictator.

>the colon is an important delimiting character, which makes having hex coded value ambiguous as well

In IPv6 or in Red, you mean?

In IPv6 the colons are there for convenience only, with the rule being that leading zeros can be omitted and that two or more consecutive groups of all zeros can be replaced with ::. You can only have one instance of :: otherwise it would be ambiguous.

For example, the IPv6 address ::1 is actually 0000:0000:0000:0000:0000:0000:0000:0001.

Likewise, 2a03:2880:fffe:c:face:b00c:0:35 is actually 2a03:2880:fffe:000c:face:b00c:0000:0035.

Once an IPv6 address has been expanded to it's full non-abbreviated form you can safely strip it of colons and use the resulting hexadecimal value to uniquely represent that address.

If you were talking about colons in Red and not in IPv6, disregard what I said.

There were 15 participants in the GitHub issue. Hardly enough people to manipulate anything, so obviously that was not the intention. Even though some 300 people are watching the repo as a whole I doubt that many of them would see that particular comment. As the parent to your comment said, a screenshot is a reasonable way to inform the others in the thread that the link has been posted.

I am against vote-manipulation of course but I don't think that this is an instance of it.

Here's an extended example.

  mkdir -p ~/tmp/xml-merge-example
  cd !$
  git init .
  
  cat > example.xml <<EOF
  <?xml version='1.0'?>
  <hurr durr='hello'/>
  <durr hurr='world'/>
  EOF
  
  git add .
  git commit -m "Initial commit."
  
  git checkout -b alternate-reality
  
  cat > example.xml <<EOF
  <?xml version='1.0'?>
  <durr hurr='world'/>
  <hurr durr='hello'/>
  <foo reality='alternate'/>
  EOF
  
  git add .
  git commit -m "Alternate reality."
  
  git checkout master
  sed -i '' -e 's/hello/foo/' -e 's/world/bar/' example.xml
  
  git add .
  git commit -m "Hello foo to the world bar."
  
  git merge alternate-reality

The attempted merge will result in the following:

  Auto-merging example.xml
  CONFLICT (content): Merge conflict in example.xml
  Automatic merge failed; fix conflicts and then commit the result.

For a quick PoC, let's create a little script that will echo the arguments that was passed to it and then exit with failure. The real script would work as outlined in the parent comment and would exit with success at the end as long as the merge worked out.

The t argument to mergetool works a bit different than I thought, but not by much -- the tool must be referenced by name and the corresponding mergetool.<tool>.cmd must have been set. In the command you use the variables $BASE, $LOCAL, $REMOTE and $MERGED as explained in https://git-scm.com/docs/git-mergetool#git-mergetool--tlttoo... . This allows tools with different argument ordering, flags and such to be used.

Let's write the PoC script

  mkdir -p ~/bin
  cat >~/bin/mergepoc.bash <<'EOF'
  #!/usr/bin/env bash
  
  echo "$0: WARN: Proof-of-Concept" 1>&2
  echo "$0: INFO: Arguments: $@" 1>&2
  exit 1
  EOF
  
  chmod 755 ~/bin/mergepoc.bash

and define the mergetool cmd

  git config mergetool.mergepoc.cmd '~/bin/mergepoc.bash --base "$BASE" "$LOCAL" "$REMOTE" -o "$MERGED"'

and tell git to trust the exit status of this tool

  git config mergetool.mergepoc.trustExitCode true

Then we run it.

  git mergetool -t mergepoc example.xml

Result (with an additional line-break inserted in order for to avoid having the contents shown here scroll sideways):

  Merging:
  example.xml
  
  Normal merge conflict for 'example.xml':
    {local}: modified file
    {remote}: modified file
  /home/erikn/bin/mergepoc.bash: WARN: Proof-of-Concept
  /home/erikn/bin/mergepoc.bash: INFO: Arguments: --base ./example_BASE_4020.xml
    ./example_LOCAL_4020.xml ./example_REMOTE_4020.xml -o example.xml
  merge of example.xml failed
  Continue merging other unresolved paths [y/n]? n

I found a program someone wrote called sortxml that will prettify and sort XML files. It's written C#. Might be possible to run it on Linux also, or to find another similar program for Linux that will. I'd investigate further if it wasn't for the fact that I rarely work with XML files.

https://github.com/kodybrown/sortxml

You may be able to write a small wrapper script that does the following: For each filename passed as argument to your script you will run sortxml on it and store the result in a temporary file, then once you've done so for all files, you pass the sorted files to an existing merge tool such as for example meld, kdiff3 or vimdiff.

Let's say that you name your script mergexml.bash and that you put it in ~/bin/. Then it should be possible to first git merge as usual but when a conflict arises in an XML file, you will run something like

  git mergetool -t ~/bin/mergexml.bash example.xml

And your script will have simplified the process.

For bonus points, you might write an unsortxml program that your script will call at the end to rearrange the nodes and attributes to be in the same order as they were in one of the original XML files -- the user would be prompted to select which of the original XML files to use for ordering the nodes and attributes.

I haven't tested this of course, otherwise I'd probably have actual code to share for it but I think something like what I've outlined above should work.

I think with any larger scale open source project looking to change license they basically have to assert that no response implies agreement because of the amount of people that have contributed over time and things that this leads to, such as the probability that at least one of them might have died or otherwise have become unreachable since when they contributed.

However they might have instead used some of the donor money to hire someone to do a clean-room re-implementation of the functionality for which they couldn't get the original author's blessing to change the license of. This might have been the more respectful thing to do perhaps.

I previously worked with Unix sysadmin tasks and software development at Statnett SF [1], the transmission system operator (TSO) for the national level of the Norwegian electrical power distribution network, and am currently studying at the university to become an electrical engineer. We started learning about transformers, generators and motors in three-phase systems this semester, so that document is of interest to me. I looked over the document briefly and intend to read it in full later, for example tomorrow when I will be going on a two hour train trip to Oslo.

The electricity sector in Norway relies predominantly on hydroelectricity. In 2008, hydroelectricity generated 141 terawatt-hours (TWh) and accounted for 98.5% of the national electricity demand. [2]

I have been told that the nature of hydroelectric power generator installations makes the act of balancing the power system in Norway quite different from what most other countries are dealing with but I think the document you linked will be informative to me none-the-less. Besides, understanding power systems balancing in general and not just for Norway would allow me to work in other countries in the future should I want to. Not saying that the university is going to teach me things that apply to Norway only of course but I hope that you understand what I mean.

PS: Statnett has a live view of the Nordic power balance on their website -- http://statnett.no/en/Market-and-operations/

[1]: http://statnett.no/en/About-Statnett/

[2]: https://en.wikipedia.org/wiki/Electricity_sector_in_Norway

In a similar fashion, some turntables have four rows of dots on their platter and a strobe light that will blink at a frequency determined by your mains AC frequency, and when the platter is moving at a perfect 33 RPM or 45 RPM, the respective row of dots for your AC frequency will appear to be standing still.

https://www.youtube.com/watch?v=LdyiFn_idpY

Of course it must be downloaded in order to display it. Obviously what I mean is that since they point out "auto-download" specifically I would think that they mean that it's saved to disk in your Downloads folder. Why this should be a problem somehow you'll have to ask them not me.

If they file size was the concern, they would have said so. There are a lot of web pages that weigh in at more bytes than this PDF these days with all of their images and scripts and god-knows-what.

I am counting on the authors seeing this thread.

Typo:

>but the ports tree is a rolling release not tight to a FreeBSD release

should be

>but the ports tree is a rolling release not tied to a FreeBSD release

The title already has the pdf tag and I think that's automatic so it was there when you clicked the link also.

The server does not send the Content-Disposition [1] header, so if your browser auto-downloads the PDF then either you've made poor choices about your browser config or you have a browser that can't itself show PDFs, in which case you may have made a poor choice of browser.

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

Thanks, I look forward to going through this course.

I wanted to point out though, that on the main page http://course.fast.ai/ the courses appear out of order; 1, 2, 0, 3, ... instead of 0, 1, 2, 3, ...

Marked dupe, why?

Is that relevant to HTTP/2, though? Does HTTP/2 say anything about DNS at all?

Thanks.

For my personal projects I often commit unfinished stuff. Using the kinds of flags you describe sounds like a good idea for projects where more people are involved indeed. Thanks.

I like all of these but am wondering what the following two mean.

Start = Begin doing something; e.g. create a feature flag.

Stop = End doing something; e.g. remove a feature flag.

Could someone explain these and give a few examples?

>maybe the solution is two or three people rather than one

Sounds like a good idea to me. Personally I would be willing to work with a couple of other volunteers as long as we were able to get along.

>Given that we run these tests on every commit, in some sense, it would be the PR author's job, but if they get stuck, we need someone who's able to help them fix that. That is the hardest part of moving from tier 2 to tier 1 in my personal opinion. Who is that person? What happens if they drop off the project?

I would have liked to volunteer as the kind of person that would investigate issues for the FreeBSD platform but as I said, both my skills and my time are limited to the extent that they might not be sufficient.

As for what happens if the person responsible for this drops off the project, I think the solution to that is not so complicated; demote the platform back to tier 2 until someone else (if anyone ever) steps up to take over the responsibility.

>So the most effective thing to do to take Rust FreeBSD support to the next level is to figure out a way to get the CI to run tests.

If I were to set up my own FreeBSD buildbot for commits to the Rust repos, would result reports from my buildbot be welcome? Would automatic reports be useful to you, or should I manually inspect failures and write up a bug report / pull request with fixes for issues that arise? If automatic, how could I best integrate reports of failure with your development process for Rust?

>There may be opportunities in the future for paid Rust platform support, where if a motivated party donates the right amount of money, we'll make it happen. I think that will have to happen to get some of the remaining platforms up to production quality.

I like this idea though I don't have a lot of money to spend myself currently.

For my own commits in my personal repos I often find that less than 80 chars are sufficient to describe the change entirely. I generally don't care about surpassing 80 chars for commit messages though, so even if my commit message is somewhat long I won't split it up.

I commit very often and usually small, "atomic" changes most of the time.

What I will do, is that I start the commit message with the most important sentence and add less important sentences after, so even if it exceeds 80 chars and you can't see the whole message you will still get the most relevant info without having to scroll sideways.

For reference, here are the commits to a project I am currently working on: https://github.com/eriknstr/jumper/commits/master

I am glad that FreeBSD is on the "Tier 2" list of supported platforms [1] but am wondering, is there any way to convince you guys to make it "Tier 1"? If so, how?

I am willing to dedicate some amount of my own time to make it happen but am not convinced that my skills [2] and the amount of time I have available to spend is sufficient to make a difference.

[1]: https://forge.rust-lang.org/platform-support.html

[2]: https://www.github.com/eriknstr

This is one of my greatest fears.

Looking at the kinds of projects they have show on the page, it seems that a GPU is not useful for most of those.

For the projects where you would benefit from a GPU, you could perhaps commicate with a bigger computer that does the calculations? Too much latency for some applications of course but not for others.

If your project really needs a GPU and it needs it on the device that is controlling the robotics components, I think probably something other than the BB Blue would be more appropriate.