I can't answer for the File Pilot author but I've spent many years on writing a file manager.
* It's fun to write and to use. It's like craftmanship.
* Hopefully some companies/people will realize how many hours they waste using the default OS file manager
* It's less risky than developing a game full time (I think)
* Sure, I lost a lot of money to not having a normal job but my bills are low and my priority is more happiness
I've come to realize (mainly by reading comments on this very forum) that, for an increasing amount of people, programming is just a job and they don't see it as an art form or a hobby. They genuinely cannot fathom that someone would spend time on ANY project without being paid.
It's very sad but ultimately society couldn't function of we only hired passion-driven programmers, so eh.
Better than asking what the money is for, even if the customer gives a reason like "buying a car", warn the customer that if someone on the phone or is unknown at your door asked you to do it urgently it's probably a scam even it they say they are from your bank/company/authorities.
For Linux, I'm using jpackage to package my Java software to .deb (x64 architecture) file. For all the other Linux variants, I've a .tgz file that contains the jar file, libraries and icons of the applications.
The problem I have with Linux is named at the end of the website: "Sharing your creation". It's pages and pages of documentation that is not relevant to the packaging of your application where you can spend hours of work without finding what you want of finding out that it doesn't work for you because for example it's not on GitHub.
Hopefully jpackage was able to fix it for the .deb format.
Instead of working on more documentation, working on better and easier to use packaging tool would help.
I don't think that what's friends are for (to test your app). Meaning, you'll need to go to a paying service, making it harder to justify afterwards to make your app free without ads or in-app purchase.
I don't even have 20 friends. But if you/your team have 15 acquaintances who are willing, you can set up five Google accounts to test the app. After all, all you need for a Google account is a phone number. Which, at least in my country, can be acquired for free without much hassle.
As a non physicist here, why not showing a video of a ohmmeter showing zero's when measuring the resistance of this material instead of its levitation?
A Meissner effect demo is usually seen as an easier and stronger proof of superconductivity than a resistance measurement, which is a delicate task and susceptible to experimental errors.
First, one cannot measure superconductivity with an ordinary ohmmeter. Electrodes, wires and the ohmmeter itself are resistive, the meter can never show zero ohms. So you can't just look at the screen read-out and say there's superconductivity, you need to set an experiment up to do it manually, with a current source and a voltmeter to measure the IV curve across the material [1]. Even then, the voltmeter will never show "zero" volt because of noise, such as thermocouple effect, triboelectric effect, or electromagnetic interference - which need to be minimized during the experiment and removed during post-processing. There are also the problems of sample preparation and purity as others have noted.
Look at how tiny the spec is. What would be the most convincing evidence? A resistence meter that basacally touches itself or a spec clearly floating on a magnet without cooling.
Looking at the implementation, it is implemented in C++. I'd rather have an implementation using the new Vector API (still in incubation). It would be more Java like and provide a good demo for this new API.
It seems like you're saying you'd rather have a slower implementation given that a bunch of single instructions useful for this sort of thing aren't available in the Vector API and must be built from sequences of Vector methods that themselves must be implemented using multiple instructions.
I think he's referring to something similar to what .NET has been doing in the last few versions. They introduced a new Vector API that abstracts platform-specific SIMD instructions. The end result is the same, code using Vector128 will be directly compiled to equivalent AVX opcodes on x86/x64 and NEON on ARM* as if you would have written that directly, except that now you can add these kinds of optimizations across many architectures with a single codebase
This [0] post by Stephen Toub goes in GREAT detail on that
You mean this IntVector[0], which I assume is the Java experimental API anthony88 was referring to, correct? If that operation being missing is a blocker, I feel there may be some middle ground other than implementing the whole thing in C++ (like adding it or fast tracking work on this API)
Hello, thanks for pointing out that I missed this one. It looks like the methods exposed may be sufficient for implementing a sort. I also looked for vpalignr and vpshufb which seem to be missing, but I'm open to the possibility that I have missed these as well.
vpalignr is called "slice", vpshufb is "rearrange". The latter is easy to find if you search the page linked above for "shuf". The former is a bit harder, but I found it by searching for "concat" while thinking about how it might be possible to express it.
If you need the vpshufb behavior of zeroing elements where the index is negative, I think you will need to build something out of multiple operations. The compiler is of course free to match those multiple operations to one target instruction, i.e., recognize that what you are trying to say is really a vpshufb. It can do this in the same way that it can match multiple operations like x + y * 8 + 12 to a single lea instruction.
Another way that rearrange is not vpshufb is that 0 in the 17th position means "get me the first byte (from a different 16-byte lane)" rather than "get me the 17th byte (from this 16-byte lane)" It would be very impressive if the compiler could take a lookup table of values designed to be used as the shuffle argument to rearrange and transform it into a lookup table of values designed to be used as the shuffle argument to vpshufb.
vpshufb only accesses bytes within the same 16-byte lane and has latency 1. Instructions that shuffle bytes across lanes tend to have higher latency. So at the 16th position, a shuffle value of 0 (or 16, or 32...) gets you the first byte (byte 0) from the other argument, but at the 17th position, a shuffle value of 0 instead gets you the 17th byte (byte 16, or byte 0 of the corresponding 16-byte lane, if you like) from the other argument. This isn't really desirable behavior. Rather, it's somewhat awkward behavior that one has to work with to avoid doing a sequence of more expensive operations.
I am concerned that it takes like 6 instructions (2 to put copies of each lane into all lanes, 2 shuffles, cmpgt, blend) including a load and using an extra register to implement rearrange for use cases that would be fine with vpshufb for 32-byte registers and maybe 14 instructions (4 to put copies of each lane into all lanes, 4 shuffles, 3 compares, 3 blends) with 3 loads and 3 extra registers to implement rearrange for 64-byte registers. Maybe you can do better for the latter case though, I haven't had a thorough try at it.
A common use of vpshufb is to get a mask of character positions from a string matching a small set of characters, which you can do with cmpeq(in_slice, vpshufb(c, in_slice)), where the input substring in_slice is used as the shuffle and c is chosen so that input characters in the set of characters of interest (e.g. {'\n' '\r' '\t' '\"' '\\'}) map to themselves and other characters map to something other than themselves. rearrange doesn't seem to define what happens when indices in the shuffle are negative or too large, so it seems like to use rearrange we need to mask off some bits and do cmpeq(in_slice, rearrange(c, and(d, in_slice))) where the `and` is only there because of the nit about invalid indices and `rearrange` is 1 or 6 or 14 instructions depending on what register width we're working with. That could be unfortunate.
You don't need this stuff for sorting primitives though!
You are still making things up about the API. If you're actually interested, look at the VectorShuffle class, its docs will tell you all about how illegal indices are handled and how to legalize them. But I doubt that you're actually interested.
It's a pity because you clearly have a lot of knowledge that you could put to use to provide very helpful feedback to implementors of the Vector API. (I'm doing this for the GraalVM compiler.)
I just read the entire documentation for the rearrange method. My apologies for not reading some unrelated docs to find out what rearrange does. It looks like this just makes things worse though? Like you really do have to mask off the high bits of the input, but then you're also paying several instructions for the mapping of out-of-bounds indices to negative values when making the VectorShuffle and then several instructions again to check whether any of them were negative so you can throw an exception from `rearrange`.
Would any of you notch punch holders be willing to let me borrow it? They're rather difficult to find for purchase, and I'm not comfortable with my motor skills with scissors, but I've got about 75 disks that need a second notch. Near Seattle, WA, USA. Can compensate with dollars or happy to share some of the disks (made in the bay area, addressed to an east coast computer builder but appatently never sent).
this was the first thing i did when i bought a 10-pack of new floppies (i used scissors). still remember that sweet box fresh smell from opening a new box of floppies
