Giorgio

@DocBrown: I did not say that code should never be changed (I do not see such a sentence in my comment). I agree that having automatic tests helps to change code, but nevertheless you should be aware that you are breaking something that was working to build something new. Being inflexible and never change anything leads to the problems you have described. Being overconfident because you have automatic tests and change code too often can produce code that is never really stable. IMO the best solutions lie between these two extremes.

@Doc Brown: "... because you did not write enough automatic tests" even with a lot of automatic tests, changing working code can introduce subtle bugs that are not detected by the tests. Changing working code is always a risk, even when using automatic tests.

I am going to have some dinner now. Thanks for the info and the chat. Maybe we catch up with each other some other time.

Which GNU/Linux distribution are you using?

I have first tried FreeBSD on an old computer for a while. Now I have decided to use it on my main PC. I do not have that much data: about 400 G in total.

How many disks do you have?

Here's the bug: bugs.freebsd.org/bugzilla/show_bug.cgi?id=214479

Anyway, I am filing a bug report right now.

I also had this problem. I copied the data to my main hard disk, reformatted with ext2, and copied it back. Before that I had installed it on a spare hard disk. You can find a second hand sata hard disk for very little money.

I have also used mainly GNU/Linux up to now. I am seriously considering FreeBSD.

Are you using FreeBSD? I have just started.

I have changed the title of the question on stackoverflow and on the FreeBSD forum. Maybe a developer will take a look at it? Otherwise I can file a bug.

Hello, thanks for the link. It is not me

@Ned64: Thanks for all the feedback. I have considered compiling the package from source and possibly inserting a few printfs to debug it.

@Ned64: More precisely: Does FreeBSD have problems using ext2fs with external USB hard drives that have a sector size of 4096 Bytes? I tested ufs on this drive and it seems to work OK.

@Ned64: The enclosures are identical and both disks are sold by the same company as 1T external drives. However, I found out that internally two different disks are used, even the vendors are different. I made further experiments and have posted a question on the FreeBSD forum (forums.freebsd.org/threads/58489).

I bought the disks with a built-in enclosure and I plug them directly on my computer using a USB cable. So there is nothing but the USB cable between the disks and my computer. Repartitioning the disks is not a problem: I am backing up my data right now, should be finished in one hour or so. I want to try using 512 logical sectors since, as far as I understand, it is not possible to change the physical sector size, because that is determined by the controller.

@dirkt: If this were the case, the problem should disappear when I remove the good drive (?) Anyway, running gpart list with only the bad drive attached gives the same result for stripesize and stripeoffset.

What puzzles me is that both disks are the same model, bought at a few months distance. Why do they have different physical block sizes?

@dirkt: However, it works without any problems under Linux. In any case, should I repartition the disk? Is it possible to change the sector size using a partitioning tool?

@wurtel: You mean read and write are disabled? I cannot find any complete documentation on the output of gpart geom so I do not know how to interpret the Mode field.

Bye bye

Ok, thanks for the hints. Maybe we meet in chat some other time.

Multiple inheritance turned out to be complex and we had a pretty sneaky bug lately

Maybe we should have considered the generic function + duck typing approach?

This is an interesting topic because we have a few places where we used inheritance in our code (at my workplace we work in Python).

Why wouldn't it be considered pythonic?

Ah OK.

What about adding a common superclass? Do you think it would be feasible?

They would all be one-liners.

Like it has to implement __iter__

Why?

Maybe

One reason not to add these methods is that there are the functions already.

My point was that it would not be difficult to add the methods. Like all collection must have an iter method, they could have a map, a filter method and so on. They could still share the implementation.

Hi, I understand your point: as soon as an object defines the __iter__ method, you can apply the generic function to it.

@WinstonEwert: Then each method can be a thin wrapper around this common function implementation using __iter__.

@WinstonEwert: What would be so bad about that? After all the existing function implementations have to discriminate between the different collections they are applied to in the same way as the corresponding methods would.

"There is no collection base class to put a map,reduce,filter etc on.": Why do you think that such methods should be put in a base class? Each collection classes could implement these methods and they would just happen to be there when you need them (duck typing).

@FaizanRabbani: Here is also on the Internet. ;-)

bye

good luck

I hope it works out, it is a cool problem anyway.

each time you do not find your function in the tree, you add a new branch

Using a dictionary you just build the tree from the bottom up

Oh, you are right, it is a tree because you only have unary functions!

Actually, if you build a dictionary along the way, you are building this DAG from bottom to top

DAG

so it is a directed acyclic graph

because you have no recursion