Posts by nezachem

First of all, both arrays must have the same size - they represent the same tree, so they have exactly as many elements as there are nodes in the tree. No need to test both sizes.
Second, in the terminating situation you should return NULL, not the root.

Third, there are way too many problems with the implementation.

You determine the array size with strlen(). This is wrong in general, because it restricts you to zero terminating strings (it also kills the asymptotics, but for now it's a least of the worries). This is wrong in particular, because the copies you made are not zero terminated.
The simplest way around - which also happens to be a correct solution - is to pass the size as a third parameter to plantBTree.

The copies themselves are also made incorrectly. For example,the RSTp loop fills up the right part of the array - leaving the left one with garbage. That garbage is then passed down to the recursive call. You need to pass RSTi + PreorderIndex + 1, RSTp + PreorderIndex + 1 instead, or copy to the beginning of the RST arrays.
Now, with the size being passed separately, copying doesn't buy you anything, and just stands in the way. You shall work directly from the original arrays. Hint: the whole function fits into 10 lines or so.

A final note: get rid of the global variables. They are bad in general, and extremely …

> Would a "sparse" check of just those file descriptors (using a set iterator) in the set be ok to use?

Absolutely OK.

Call GetLastError() and display it with FormatMessage(). That will give you textual explanation of why "Attempt to bind failed".

Besides that, the port value in sockaddr should be in the network byte order. Use htons() (or a whatever winsock provides for that matter). sin_addr is also conventionally assigned via interface function (like inet_addr() or inet_aton()).

Finally, it is highly recommended to zero out the entire sockaddr before filling it up.

Because it is an integer division. 3/2 yields 1, not 1.5

The only thing I may recommend now is to put a breakpoint at checkWord and see what data are passed there. I have a suspicion that wordtwo may contain characters you do not expect (such as a newline).

Arguments for strcmp must be terminated with 0. Your wordone and wordtwo are not: they are arrays of 4 characters, and all four are filled up with input. The trailing garbage they have is different thus causing strcmp to report inequality.

Please post some more details:
- How does it crash?
- Does the executable have debug information?
- Do you have sources?
- What does ulimit -c report?

The url3 has too many % signs. The %20e sequence tries to format an argument as a floating point into 20 characters.

Change stray %s into %%s: Authority%%20eq%%20'%s'&$inlinecount

To do what?

The code you suggested leads to the race with a high chance of a deadlock:

write(fd[WRITE_END], write_msg, strlen(write_msg) + 1);		
		while (read(fd[READ_END], (char*)&ch, sizeof(char)), ch != '\n')
		{
			...
		}

Here the parent would immediately read back whatever it just wrote, eventually leaving both processes hung at the read().

The only way to establish two way communication is to set up two pipes.

Take a close look at line 25. Are you sure you want a shift to be logical?

You are almost there.
Pay close attention to the following:
1. Line 3 - you declare the last argument as an array of pointers. Do you need an array? No, you need just one pointer to a value.
2. Line 22 is correct. However the assignment at line 27 is wrong. The error message clearly tells you so: cannot convert `bool' to `int*' in assignment. You do not want to assign to output , but rather to whatever output is pointing to. *output = would fix it.
3. Last, but not least. For mux() to do something useful, you have to actually call it.

> Pragma once is suppose to help, no?

No. Pragma once only helps against multiple inclusions into the same translation unit (read, same .cpp file), that is, at the compilation time.

Your situation is different: Average Calculator.cpp and PaintHandler.cpp both independently include Average Calculator.h; they are both independently compiled, and therefore both independently declare the instance of hEdit. Linker complains.

You need to make sure that hEdit is declared extern in all files except one.

Another hint: take the differences of your sequence (that is, f(n) - f(n - 1)). You will see the pattern very clearly.

You have a few language problems there, such as
- control[0]! is invalid C (you need !control[0] ),
- output must be passed by reference, or returned,
- nux is used prior to declaration

Otherwise, you've got the idea. Looks OK to me (but -- I am not your professor).

Line 95: you are copying an original array on top of what you just calculated. You want it other way around.

That seems to be right.

> So I was wondering if I am doing this right?

Certainly not.

The mux has 8 data inputs, and 3 control inputs. Remember that the 3 bits of control represent a number from 0 to 7. The number is the index of the input which should be copied to output. As simple as

bool mux(bool * controls, bool * data)
{
    int control = controls[0] << 2 | controls[1] << 1 | controls[2];
    return data[control];
}

However, it is not what the assignment is about. You need to simulate the mux at the gate level. See for example the schematics of a 4-to-1 mux. You need to draw a similar one for 8-to-1, and implement it.

> why the compiler(gcc) outputs a warning

Because your main is (correctly) declared as returning int, but does not actually return anything.

> Ok, so what does the video memory get placed in the pallet memory?

Please please please read the VGA spec.

> Shouldn't this display a red pixel at position 4

No. It sets the Red component of a fourth palette entry to 255. It does not display anything. To display something you need to move some data to the video memory. How to do it exactly depends on the selected mode. In some modes the value written to the video memory is an index to a palette: the pixel containing X is of color described by the palette entry number X.

Consider the following:

mov al, 4        ; Select entry 4
    mov dx, 0x3c8
    out dx, al

    mov dx, 0x3c9    ; Prepare to write components
    mov al, 255      ; Red
    out dx, al
    mov al, 0        ; Green
    out dx, al
    mov al, 0        ; Blue
    out dx, al

This sets the entry 4 to a pure red. Whenever you write 4 into a video memory, the corresponding pixel would have that color.

First and foremost: 0x3c8 has nothing to do with the video memory. It sets a pointer into a palette memory.
The value you put there is a palette entry number. A value 10 would make it point to 10'th entry. You may say is a 30'th byte; however the palette is not byte addressable, so counting bytes there makes little sense.
Yet again, it does not point to any pixel.

Now that you got rid of errors, it's time to read more on VGA. Writing 4 to the port 3c8 sets the internal pointer to the 4th palette entry. Successive write of 4 to the port 0x3c9 sets the Red value of that entry to 4. You probably want two more writes to the same port to complete the entry with Green and Blue values.

If you want to see something on the screen, read here for example. And again, read the documentation carefully. VGA is a very unfriendly piece of silicon.

Read the documentation carefully. You manage to violate practically all restrictions for the out instruction:

out	Output (write) to port
  Syntax:	out	op, AL
  		out	op, AX
  op: 8-bit immediate or DX
  Action: If source is AL, write byte in AL to 8-bit port op.
          If source is AX, write word in AX to 16-bit port op.
  Flags Affected: None

1. You may not output ah. Only ax and al are valid
2. You may not have a 16-bit immediate as the port number.

So,

mov dx, 0x3c8
    mov al, 4
    out dx, al

[]

> I read it from the file and insert it
Unless your Insert() duplicates the structure, all the nodes will point to the same place.

> I can't grasp the difference
Consider the following:

struct employee emp1;
struct employee * emp2 = malloc(...);
fread(&emp1, ...);
fread(emp2, ...);

emp1 is a structure, and we pass its address. emp2 is an address already. fread(&emp2, ...) would fill up not the memory allocated and pointed to by emp2, but the memory occupied by the variable emp2 itself.

Few problems here.
First, there's only one struct employee allocated (line 4), and would be written over and over with each new record.
Second, I said "would be" above, because &emp in the fread is wrong; it should be just emp. Can you see the difference?
Third, it is very much suspicious that the elements of tree (line 3) are not initialized in any way. I bet that it confuses Insert big time.

PS: you are absolutely correct that reading the whole tree from the file is wrong.

The variable is just some (named) piece of a computer memory. It always has a value. Before you assign something to it, the value is garbage: useless, unpredictable, yet a value. This is why initialization is so important. Fix your program by initializing:

int smallest = INT_MAX;

Your server closes new_socket after each message it receives. Your client, on the other hand, sends all its messages over the same socket. That is, the second message is sent through the socket which is already closed. Therefore, the crash.

Rethink your design. Either let the client reestablish connection for each message, or make the connection persistent at the server side.

> Your suggestion is no different than Narue's.

No. Consider a scenario:

1. Open file for read - open succeeds; presume that the file didn't exist
2. Open file for write to do an actual job
So far so good, until another process creates the file right between step 1 and step 2. This is what is bad when test and use are separate.

CreateFile does it atomically, thus avoiding the race.

> Try to open it for reading. If it opens, it exists.

This approach suffers an inherent race condition. Moreover, in most cases (including this) such test is redundant. Both windows and posix systems provide an atomic solution to the OP problem.
For windows it is CreateFile with the disposition CREATE_NEW. For posix, it is open with flags O_CREAT | O_EXCL .

This is just one of the issues, and you are definitely made a correct move.
Now, the 'c' object in c.execute() is undefined (you have conn, you have cursor, but what is c?). The fact that python doesn't complain means that the c.execute line is never actually executed. It means that most likely the script never progresses beyond s.recv().

The semicolon at line 15 means that the code actually is

while (( n = fread(buffer,1,sizeof buffer, original_pointer)) > 0)
    /* Do nothing */
    ; /* End of loop */
		{
		fwrite(buffer,1, n , copy_pointer)

and fwrite is called once, after the loop finished, with n equal to -1.

Also, line 1 doesn't do what you want to.

Unless using awk is mandatory, I'd recommend using join .

Typo correction: a 16-bit register may contain data in the range of 0..65535; 255 is a maximal value of an 8-bit register.

Regarding Eclipse, I am as illiterate as you are. However, I know for sure that Eclipse works very well with cygwin. I do recommend to either
- redo the whole import again, making sure that at each step the cygwin compatible option is selected, OR
- find all makefiles and their fragments of the project, and replace the paths cygwin style anywhere they are spelled out.

The standard recommendation is to replace all the windows style paths with cygwin paths, such as /cygdrive/d/FRODAN/whatever. make dropped support for windows style paths since at least 2006.

There are some reasons not to do this. First and foremost is cross-platform portability. A syscall is a unix artefact, while read/write/whatever are supported on any posix platform (and even on some others). Second, the syscall is prototyped as vararg, which prevents the compiler from error checking.

Calling it directly doesn't look too straightforward to me; elimination of the proxy call gives an infinitesimal advantage time wise, and you still need to link libc for all the other goodies it provides.

Edit: since you are interested in the assembly, disregard my prototyping argument.

It is very important to understand that an application and the kernel reside in different address spaces. It means, among other things, that the application possibly cannot call anything in the kernel; the only way to "call" it is through the syscall mechanism, which essentially is the interrupt. This answers your first question: anything the application calls is linked in the libc.

The implementation of some functions, say read, or write, contains a syscall. Their job essentially is to provide a call number (which is hardcoded into the function), and call syscall(). Again, since the kernel cannot easily access the application stack (as it is in a different address space), the job of syscall() is to arrange its arguments in registers, and perform the interrupt.

> Simply using syscall with the call number for a particular machine would not be portable (obviously)

On the contrary, it is portable. The syscall numbers never ever change. The particular kernel version may not support a particular syscall, but the same number always refer to the same syscall.

You don't want to deal with interrupts, unless you are in an OS-less environment. For Windows, read this.

Here's a fairly crazy proposal:
Pipe your files through sed -e 's/^#include/INCLUDE' prior to gcc -E, and then back through sed -e 's/^INCLUDE/#include/' (all that assuming that you don't want to expand any of your includes, and no line in your code begins with INCLUDE; in any case, the sed command could be tailored according to your needs). This is very much ad hoc, but I doubt there is a clean solution..

1. The compiler sees the call to getdet at line 4. It has to assume something about this symbol. The assumption is that it is a function returning int. At line 6 it sees that getdet is a function returning a pointer. This mismatches its previous assumption. Warning is emitted.
To avoid the warning, you have to be explicit: add a declaration

short int ** getdet (short int **m , int n);

above main.

2. You are trying to calculate a determinant - why returning the pointer at all?

Few problems here.
1. Design problems.
1.1 You declare the function as void, yet in some cases return a value. Make up your mind (should I write a function like this, I'd declare it int and return the file descriptor).
1.2 The function opens just one file; therefore it needs just one argument. Yet you pass it the whole (counted) array of them.
That is, the proper declaration should be

int outputFile(char * filename)

2. Implementation problems.
2.1 A stat/open combination is a race condition (imagine another process creating the file right in between of a (successful) call to stat and a call to open). Don't do that.
Besides, it is redundant, because O_CREAT | O_EXCL flags do force open to fail if the file exists.
2.2 Error message at line 17 is not informative.

3. Too many unnecessary (and even undeclared) variables. What is inode, what is i?

All that said, the function becomes

int outputFile(char * filename)
{
    int file_desc_out = open(filename, O_CREAT | O_WRONLY | O_EXCL , S_IRUSR|S_IWUSR);
    if (file_desc_out == -1) {
        perror(filename);
    }
    return file_desc_out;
}

It links in the librt.so, the library which provides (among other things) implementation of the sem_* functions. Ask me not why this library is called rt; however, see the Linking section of a sem_overview manpage.
PS: it is important to realize that sem family is not related to pthread family whatsoever. The fact that posix semaphores, pthreads (as well as System V primitives) coexist peacefully in the same system is one of the marvels of unix.

> I calculated that this function gives the number of sequence that sums to a number n

I seriously doubt that.

> gcc filename.c -lpthread
is not enough. You also need -lrt

inotify is what you are looking for.

would something like this be better?

A step in the right direction, for sure. In the updated version you can easily identify the Factory, and factor it out, for example:

int main()
{
    while(true) {
        subsystem = Subsystem::open();
        subsystem.execute();
        delete subsystem;
    }
}

The static open() method deals with the user input and instantiates the proper object.

Always test the return values of the system calls. In this case, is ShmID valid? What is errno after shmget? What is errno after shmat?

This could be helpful.

I agree that the code is not polished. I disagree though with the proposed "encapsulation of ifs". Your approach requires 25 comparisons for each non-accented letter - just to leave it alone. Really wasteful, isn't it?

Consider a redesign based on a lookup table. Such table indexed by the original character, with the value being a the substitution one. For example, translate[0x83] is 'a', translate[0xc6] is also 'a', etc. This way the code collapses to a short simple loop:

for(x = 0; x < strlen(texto); x++)
        text[x] = translate[texto[x]];

Of course, you need to put some extra effort to populate the translation table.