HN user
Yes, exactly. Git worktrees will for instance make it easier to merge changes between multiple checked out branches without pushing upstream.
For big repositories with long histories (like Qt), worktrees also save some disk space.
One way to get an error when retrieving a git hash is by building inside a Docker container. If you mount the root directory of a work tree, but not the “git-common-dir”, git will fail to give you the commit hash.
Maybe you saw it in his video called "You suck at Excel" [1]? It is in any case worth the watch.
From experience, I can also recommend using SQLite as an application file format. I landed on SQLite after looking for solutions for a file format for an educational app we made for simulating biological neural networks. The app is cross-platform, written in Qt and the simulations needed to be stored as a JSON describing the network, a thumbnail and some metadata. It was also intended to be extensible with more features and backwards compatible if new versions were released. I considered creating our own simple format, using ZIP files, HDF5, Qt resource files or SQLite.
I landed on SQLite for many of the reasons outlined in this article and in particular because of how easy it was to implement and maintain. SQLite is supported natively in QtSql, which made it extremely easy to write the save and load functions, and later extend these with more data fields. In addition, we did not have to worry about cross-platform support since this was covered by SQLite and Qt already.
That explains! Thanks for pointing it out.
It may be a regional difference, but the link goes to a book narrated by Wil Wheaton for me. I found Wheaton's narration to be a great listen. He's not the slow-paced, calm narrator you will find in many other non-fiction audiobooks, but rather an enthusiastic storyteller. For this book, I think it was a good fit.
We recently published a paper suggesting an alternative to HDF5 [1] using directories for objects, YAML for metadata and NumPy for data. Many of the points in this article were raised by the reviwers or were worries we had about choosing YAML as the metadata format. In the end, we decided to use a subset of YAML with only basic tags, enforced quoted strings, no directives, and no block scalar styles (fancy multiline strings). So far it has worked out great. I hope it will make the format easier to understand for users and make it possible to write faster parsers in the future.
[1] Shameless plug: https://www.frontiersin.org/articles/10.3389/fninf.2018.0001...
Thanks for clarifying! I really don't think you're shifting the goalpost. What you're saying is basically that the getText/setText methods are part of the API of the visual TextField, like a moveLeft method would be part of the API of a robot controller. A dumb struct with mutable members, such as a Point with public x, y, z members, is on the other hand both the API and the data in the same object.
It seems to be important to separate data from logic, and API from implementation in discussions like these. Sure, I can make a nice API for a visual Rectangle object with dynamic width and height, and add a check to my setWidth method to make sure the width is never negative and the changes trigger a repaint. But if I need a Rectangle struct to store data in the implementation of my library, it can be way simpler to just make the Rectangle have a public final/const width member, and set and check the width in the constructor.
Sometimes you need the smart Rectangle, and sometimes you need a dumb struct with width and height.
You have a good point, but there are some cases where I have a hard time seeing how you would avoid getters and setters completely.
Say you are creating a UI library which has a TextField class. What should the TextField API have in place of the usual getText/setText and isEnabled/setEnabled methods? Say, if the library should support developers who want to create a text field that is automatically filled with data on a button press and can be disabled when a checkbox is ticked.
Note that I'm not arguing against you - I'm honestly curious about what the TextField should be replaced with or what its API should look like.
Sorry, but I did not intend to compare or conflate the two cases. I wanted to give an answer to the parent poster why those countries might be listed on the above site.
I did not mean to compare the two cases at all and am sorry if it came out that way. I just wanted to answer the parent post on 'what the "anomalies" this site detects in Denmark, Finland, and France represent' by pointing out that TPB is blocked/censored in these countries. I only meant to point out one possible reason why the above site listed these countries.
Denmark, Finland, France and many other countries censor The Pirate Bay: https://en.wikipedia.org/wiki/Countries_blocking_access_to_T...
If you want to quickly add new tasks to your todo.txt from the command line, I strongly recommend http://todotxt.com/ It is a fantastically lightweight solution and has an Android app for those times when you are not in front of a computer. The Android app just reads/writes to the same todo.txt file over Dropbox.
I think that Dropbox typically handles conflicts quite well, and the issues I had are more likely bugs outside the conflict resolution implementation. I was a bit brief in my comment above, so let me elaborate in case you or someone else is interested:
The issues I had didn't result in conflicted files. Rather, after making a big change (i.e. switching git branches) some files were never updated or synced. Dropbox stopped picking up changes in the folder and eventually removed new changes once restarted.
The order of events were something along the lines of:
1) Did work on computer A that caused massive file changes (i.e. moving between git branches). 2) Moved to computer B to continue work. 3) Noticed files were old or missing on B. 4) Syncing files in some other folders worked, but nothing happened in the folder with missing files. 5) Restarted Dropbox on both machines in hope that this would trigger a fresh sync. 6) Observed files being reverted to old versions or deleted on machine A.
The end result was that Dropbox threw away the changes I had made on A and left me with the original state of B. I was able to recover the changes from a backup, so it was no big deal in the end (although it left me a bit scared I could have lost those files without noticing).
I was in contact with Dropbox support about the issue and explained in detail what I had done and what happened. I was offered help to recover the files, but since I had already done so, I just told them I didn't need any more support on the issue. I thought it might be because /proc/sys/fs/inotify/max_user_watches had a low value on one machine, so I wrote back that they might want to add back the old warning about this. However, the same problem with deleted files happened again after I had verified that this value was high enough on all machines.
I have also seen how a script run by a colleague managed to confuse Dropbox. The script was running a test which repeatedly created and deleted the same file before checking its correctness. Running the script in the Dropbox folder left him with some old version of this file and a failed test. Running the scirpt in a folder outside Dropbox left him with the correct final version of the file. He was only working on one machine.
And yes, I know it's "bad" to run scripts like this or switch git branches on top of sync software, but it happens, and it is interesting to see how different software handles these cases.
It should be noted that Dropbox usually handles these massive file changes well, so moving to Syncthing has for me been more about it being open source and the possibility to keep files on my own machines. I was just glad to see that Syncthing also handles heavy use cases gracefully.
It amazes me that Syncthing handles rapidly-changing files better for me than Dropbox. Where Dropbox has left different versions of files on different computers even after they have changed multiple times, Syncthing happily synchronizes them without issues. And the fact that Syncthing is open source and allows me to keep files on my own machines is a big plus. However, I would love to see a paid option for easy backup of selected files to a machine in the cloud. Some people want their files backed up and accessible through a web service and I wish I could recommend Syncthing to them as well.
My thoughts exactly. Just close the popup and open any Google app to verify that you cannot access the app without signing in again.
Here is a demo of a QML sandbox in the browser using Qt+Emscripten if you are interested[1]. And the blog post in which I wrote about it[2]. It's quite big and not very well performing, but Qt might be useful for larger web apps one day.
[1] http://ovilab.net/projects/qt-emscripten/qml-sandbox/ [2] http://dragly.org/2016/04/27/experimental-qt-and-qml-in-the-...
One very good reason to use Qt is QML. It's just such an amazing language to work with for creating GUIs and is also a great way to learn declarative programming. And it is easy to mix QML with logic in either Javascript or C++ if you want to. Every time I work with anything else, like HTML+CSS, I just miss working in QML.
I don't have a lot of experience with Electron apart from working on some Atom packages. Electron seems like a good choice to me if you have existing code or libraries in JS that you want to reuse. Or if you want to make a combined web+standalone app. But if you want something that's fast, cross-platform and fun to develop, I would go for Qt.
It isn't optimal, but it used to work. I kept C++ projects on Dropbox in addition to Git because I work on multiple computers and want to be able to continue where I left off if I get interrupted. I don't like the idea of having to commit and push to git for all work in progress, even if it is on a separate branch.
The default setup in Qt Creator is to have a build folder next to the sources, but after the first big sync failure I configured Qt Creator to always build outside of Dropbox. But I experienced failed syncs after that, even with only C++ sources inside Dropbox and when building Doconce+LaTeX projects.
syncthing-inotify works great! I have been running Syncthing with this plugin for about a month now and I haven't had any problems with it.
I started using Syncthing for some of my projects after Dropbox stopped syncing files without notice for the third time. The failed Dropbox syncs were related to either C++ or Doconce+LaTeX projects where many temporary build files were being modified often. Syncthing doesn't seem to have a problem with these files, and it is even possible to configure Syncthing to ignore specific file patterns if you just don't want it to sync such files at all.
Another feature I really like with QtQuick is how intuitive it is to design in QML. The declarative syntax is great in comparison to writing GUIs in C++. After all, I don't care about in which order the GUI elements are added to the window (which you have control over in C++), as long as they end up in the right place. The syntax also feels much more modern in comparison to alternatives like HTML/XML. After trying multiple ways to design GUIs in different languages over the years, QML is the best working alternative I have found. Most of the time I even find it easier to use than a visual design tool.
In principle, yes, but I don't think Emscripten can do anything automatically the way things are now. The QML sandbox requires that almost all of QtCore and QtQuick is available because almost all code can be called by the user at runtime. Manually removing code you know is unused might be possible, though. I think I might have heard of some third-party tools that could help with this.
Thanks for the kind feedback. I really only put the icing on the cake, though. The real credit for this port goes to msorvig and the other contributors. And of course to all Qt contributors who have made this amazing framework easily portable to new platforms.
Blog post author here. I don't know how small it can become because I haven't looked into optimizing for size yet. However, we can look to the native Qt libs to get a ballpark answer to your question. I just tried gzipping the binary .so files of QtCore, QtOpenGL and QtQuick on Ubuntu and that takes up 3.9 MB. That is likely a theoretical lower limit of what needs to be downloaded by the user, but I don't think we can expect anything close to that after compiling to JavaScript. Perhaps WebAssembly will help reduce the size in the future.
In any case, I wouldn't exactly recommend building a blog using Qt this way. If you want to try building websites with QML, qmlweb is much better suited. I rather expect Qt+NaCl/Emscripten to be useful for larger browser applications, like 3D graphics software, games, scientific simulators, and so on.
Blog post author here. It loads pretty fast for me, so I guess the problem isn't bandwidth. If you see any errors in the console (right click -> Inspect -> Console), please let me know.
As for business cases, I'm personally working on a couple of simulator front-ends in neuroscience and materials science that can be made more easily available by distributing them in the browser. If not the full version, a demo could be made to show the features. Also, I find it easier and more fun to make interactive illustrations for education in Qt/QML than pure JavaScript.
I believe that is what KDE is trying to achieve with "activities".
Qt and Qt3D. I haven't contributed as much to Qt as I've wanted to, but the little I did was met with support and great mentoring. They are a very talented group.
If you're interested in physics, mathematics or other sciences, I'd recommend SciPy. I attended one of their conferences and met many really nice, kind and talented people. (Open Source conferences and meet-ups are a great way to get to know people and kick-starting contributions.)
It's great to see that the OSC module is being added to JUCE! In our lab we are working on adding OSC support to OpenEphys (an electrophysiology software that uses JUCE). Currently we need to bundle or statically link oscpack on Mac and Windows, but with OSC support built into JUCE we won't have to deal with that anymore.
By the way, does anyone know of a good comparison of OSC and ØMQ (ZMQ)? I'm curious about when to use which of the two in terms of latency and ease of use, apart from that OSC is built for audio while ØMQ appears to be more general purpose.
I didn't at all think about the terminal/computer difference when I wrote the above. You are absolutely right that this wasn't the best example.
Yes, there are definitely codebases out there that are older. I remember reading about how Emacs is tested by volunteers on older systems just to make sure new changes don't break compatibility. I think such stories are really interesting because they reveal the history behind the software we use today. And in some cases it makes sense to support older hardware, considering how much of our society still runs on old, but stable, computers. Thanks for mentioning CICS - that was new to me.
What struck me as interesting with the old code in NEURON is that NEURON is a high performance simulator still in heavy development. There appears to me few good reasons to run a simulation for a year on a Tektronix 4010 that would take a minute on a laptop. So while I wouldn't be surprised to see Emacs' old stuff still being used, I would assume that NEURON's old code is simply abandoned and was never cleaned up.