Posts by nezachem

Look at line 26. Anything suspicious there?

char args[7][50] and char * args[7] are completely different creatures. The former is an array of 7*50 characters, while the latter is an array of 7 pointers.

A function foo taking char args[7][50] would have have a signature foo(char[][50]) ; it is vital to know the width of such array to work correctly. There's no way to pass such information to a function of exec family. You must hand them an array of pointers. For example,

char * real_args[7];
    real_args[0] = args[0];
    real_args[1] = args[1];
    // etc;
    execvp("compute", real_args);

Closing the listening socket is a right way to go. Then accept() returns -1 and sets errno to EBADF, as you already observed. You just need some more logic in the "threading stuff" to analyze what have actually happened. For example, test not_ended: if it is false, you know for sure that the error is intended, and that the shutdown is in progress; otherwise you may want to do whatever recovery is necessary, and restart the listener.

Search this forum for why using eof() is not a right way to control the read loop.

do {
    mystream.getline(line, 100);
    mystream >> country_name >> happiness_value;
    total_happiness = total_happiness + happiness_value;
    count++;
    outputstream << country_name << " \t \t " << happiness_value << endl;
} while (!mystream.eof());

In short, to trigger eof() to return true, you need to read beyond the last character of the file. The last good read reads up to (and including) the last character, and no more; eof() is not triggered, and the loop runs one more time (hitting eof right away). In this last run nothing gets read, and your variables retain their values from the previous pass.

The right way is

while(mystream.getline(line, 100)) {
    ...
}

You did it backwards. msgctl copies data from the buf to the kernel space. So, you need to modify BUF with the desired values, and then call msgctl.

Keep in mind that BUF as it is contains garbage. Before any other operations fill it up with the correct values via IPC_STAT.

In the circular queue you may not rely on relative head and tail positions. You must keep track of the number of elements manually. Extend the struct queue with an int count initialized to 0. Increment it on every enqueue and decrement on every dequeue operations. Rewrite is_empty and is_full to inspect the count and act accordingly.

Of course, upon reaching the end of array, head and tail shall go back to 0.

PS: I'd recommend to test the queue state inside enqueue and dequeue.

What does mkNode return? Or, to put it other way around, why mkNode returns nothing?

The problem is with parent closing the write ends too early, so that the corresponding file descriptor is reused in the next pipe() call; bottom line is, at the read() time parent attempts to read from the closed descriptor.
Comment out lines 28-29 and see for yourself.

PS: always test errno after every system call.
PPS: I don't know how to debug a child in eclipse.

Do svn add images first. Then svn commit images .

firstnode never changes. AddToList is passed the _value_ of firstnode (which is NULL), and operates on the local variable. Upon return, firstnode remains NULL.

You have to either pass an address of firstnode,

void AddToList(LankadLista ** listaptr, char name[])
{
    ...
    *listaptr = newnode;
    ...
}

main()
{
    ...
    AddToList(&firstnode, ...);
    ...
}

or return the modified local:

LankadLista * AddToList(LankadLista * lista, char name[])
{
    ...
    return lista;
}

main()
{
    ...
    firstnode = AddToList(firsnode, ...);
    ...
}

> of maybe using pointers

Wouldn't help. A compiler is smart enough to do that for you. In fact, any code-level optimization will gain you very little.

Looks like you are multiplying matrices. Strasser algorithm is a way to go.

> a print statement did not execute means practically nothing. Load it in gdb, set a breakpoint at the moveFile, and run. This is the only way to know for sure what is going on.
I would do it, but I am away from my linux box.

> a print statement did not execute means practically nothing. Load it in gdb, set a breakpoint at the moveFile, and run. This is the only way to know for sure what is going on.
I would do it, but I am away from my linux box.

Most likely, it is dying at line 32. You have to allocate writable memory for the whole backup filename.

The entry returned by readdir is statically allocated. That is, you end up with only one instance of it, and all the pointers in the files array will have the same value.
You need to hold each d_name individually: replace line 41 with

files[count] = strdup(entry->d_name);

> Care to elaborate?

Hint: what is the value of col at line 180 after the first iteration?

Your Deal function is very very wrong. It may cause all sorts of problems (including the one you observe).

I think you've misinterpreted the situation. The {} is specific to the find utility, and has no special meaning for xargs (in fact I wonder how they are parsed at all in this context). The latter forms the command by appending the input string (as a last argument) to the given set of arguments. To summarize, a filename is mentioned in the lame command line just once.
I don't think there's a one-line solution which involves xargs; you may consider the find's -exec option. If I were you, I'd make a small wrapper script to invoke lame properly.

The way you set it up is suboptimal. Usually each object file has its own list of dependencies; having just one _DEPS for everyting leads to excessive recompilation. A typical solution uses g++ for dependency generation:

# Each .cpp will have its own .d, and the list of a dependency files is created from the list of sources:
DEPS = $(SRC:.cpp = .d)

# Same story with objects:
OBJS = $(SRC:.cpp = .o)

# A generic rule to generate a dependency (.d) file from a given .cpp:
%.d: %.cpp
    $(CXX) $(CFLAGS) -MM $< -o $@

# The generated dependency file is in fact a makefile fragment; include them all in the master makedile:
-include $(DEPS)

As you noticed, a naked * is expanded to the contents of the directory. Inside the double quotes the globbing is suppressed:

echo "$line"

It is important to realize that the child process cannot possibly affect the parent's environment. When you run the command from the executable file, a second copy of bash is forked, it has its environment changed and then dies leaving no trace. The builtins (dot and source for example) are executed in the context of the current process, without forking a child, and the environment modifications stay put.
To make a simple one word command, you may wrap it in the function, and have that function in .bashrc, or some other autosourced file of your preference.

> step around the compiler protection...
... straight into the undefined behaviour.

fgets() (line 15 of the original post) reads not only the command line, but a trailing newline as well. The newline is never stripped, and after tokenization it is still attached to the last argument. See an extra empty line (line 3):

/bin/ls /
/bin/ls    /
    
/bin/ls: cannot access /
: No such file or directory

That is, /bin/ls tries to access the "/\n" directory, which of course doesn't exist.

/bin/echo obviously doesn't care.

Are you trying to execute the makefile? What about just typing make at the command prompt?

Some numbers are both multiple of 3 AND a multiple of 5. You count such numbers twice.

A separate dll is not necessary. dlopen(0, ...) gives a handle to the main module.

I see that the thread is solved. However, using __DATE__ and __TIME__ (which are stanadrd predefined macros) looks more straightforward...

Is there any benefit to using a child process with fork()?

Definitely so. Doing everything in the same process means that you can either accept or serve. The act of serving (read the request, prepare, and send the reply) is time consuming. That is, server becomes unresponsive.
NB: it is possible to make a good server in a single process, but it is way more complicated.

If I were to do that would I just write the above into a string array and then use the send() function?

Yes.

Plus how will the index.html page be sent?

use the send() function. Don't forget an empty line after the headers.

This is the output on Solaris in the case of vfork():
Segmentation Fault (core dumped)

A vforked child is confined to _exit() and execve(). Anything else causes undefined behaviour.

MS-Windows creates threads just like vfork, where all threads share the same memory.

It does not. After vfork the parent process is blocked until the child does either _exit() or execve. Parent and child never run in parallel while sharing memory space.

But i must confess that i still dont understand , even if fork uses different memory spaces for parent and child, how the ftell(fp) points to a different value after child exits.

The point is that even though parent and child have distinct FILE objects, both of them refer to the same file obect in the kernel. The parent's ftell() obtains the read pointer from this shared object, which is of course affected by child's read().

while(!feof(sendFile)){
    fgets(send_buffer, MAX_LEN, sendFile);
    send(new_fd,send_buffer,sizeof(send_buffer),0);
}

fgets reads a line. Most likely it is shorter than MAX_LEN. However, send() will transmit MAX_LEN bytes anyway, including all the garbage beyond the end of line.
Change sizeof(send_buffer) to the actual amount of data, e.g. strlen(send_buffer).

En is set to 0 at line 11 and never changes after that. Therefore the loop (as long as E is positive) never executes. You need to initialize En to a really big number and reevaluate it at each iteration.

Adak: The code compiles and runs, and the %lf conversion apparently works. What gave you the idea that OP has trouble with floating point?
> Whether that works or not, depends on the relative sizes of integers and doubles, and your compiler design
The int to double promotion is a language feature, and it works always.

The result of OR is true if the first operand is true. Therefore, if it is the case (and it is, since i++ yields 1), the second operand (that is, j++&&k++) is not calculated at all. Such behaviour is required by the Standard.

Just check errno. It should be set to EINTR.

Line 17: Child::Add takes 2 arguments. Line 28 calls Add with 1 argument.

Besides checking a return value, allocation is OK. Lines 22-24 look strange though. A simple

CircleP circleP = allocateMem();

is enough.

Your printing loop counter is j, but you print x.

In that case I need more details on your link process and the build environment. In any case, the idea is to undefine the symbol after it had been resolved for a.o object. If you are using gcc, the following link line may help:

gcc a.o stub.o -u _CREATE_SAMPLING_PORT b.o ...

where stub.c contains your stub implementation; make sure the stub function is called CREATE_SAMPLING_PORT (without the STUB_ prefix). You have to force this particular order of files and options in the link command line.

I don't think the link time solution is simple (if possible at all, depending of your build process). On the other hand, adding

static inline CREATE_SAMPLING_PORT()
{
    STUB_CREATE_SAMPLING_PORT()
}

to your a.c will do what you want.

I hope we would not get into a holy war.
I just want to emphasize that the bug report about double hyphen was filed against expat, and rejected due to the restriction I quoted above. Now, the restriction is uncalled for, counter-intuitive, and even stupid - but it is a part of the Standard. Which makes BeautifulSoup non-compliant.
Funny, isn't it?

I am afraid you are out of luck. w3 asserts that the string "--" (double-hyphen) MUST NOT occur within comments.

The string returned by asctime contains an embedded colons and a newline, which are forbidden in Windows filenames.

1. Sed can address lines by numbers:

sed 1,3d

will do the job of your greps.

2. When inserting the comment, watch for an existing sharp:

/^[^#].*Watchdog/s/^/#/

3. You can issue multiple commands to a single sed invocation:

sed -e '1,3d' -e '/^[^#].*Watchdog/s/^/#/'

So, finally:

crontab -l | sed -e '1,3d' -e '/^[^#].*Watchdog/s/^/#/' > /tmp/crontab.a

> gcc.exe "D:\Documents and Settings\Riikard\Desktop\Untitled1.c"

You are trying to compile a C++ code, yet tell the compiler that it is C. Rename your sources to .cpp

I suppose so. The g++ you are using is not a cross-compiler, it targets the host, that is generates the intel assembly. The compiler that targets MIPS (judging from your makefile) is $(XTOOLSPREFIX)/bin/mipseb-linux-g++.
To obtain a MIPS assembly, use a following makefile:

inclide mips.mk
file.asm: file.cpp
    $(CXX) $(CXXFLAGS) -S file.cpp

That is, assuming that the makefile you posted is called mips.mk, and the assembly suffix is asm; substitute them appropriately. Don't forget that a whitespace at the last line must be a hard tab.

I am just trying to clarify: are you actually Compile using: g++ file.cpp -S?

How is your g++ configured?

> That ends the debate.

Well, as programmers we must realize that the debate never ends. Besides, neither approach looks pythonic enough to me. Since you already have the performance test set up, could you add the following?

def loop(text):
    def looper(t):
        while True:
            for c in t:
                yield c
    return looper(text)

def crypt(text, passwd):
    crypto = []
    for (t, p) in zip(text, loop(passwd)):
        crypto.append(chr(ord(t) ^ ord(p)))
    return ''.join(crypto)

First of all, try an explicit path: module = dlopen("./rules.so", RTLD_LAZY); Second, the environment variables are not exported by default. LD_LIBRARY_PATH=. is not enough, you need export LD_LIBRARY_PATH Finally, (it doesn't cause the problem though), you don't have to link your so: -lrules is unnecessary.
Maybe, there's more (I don't have a linux box at a moment).

> But I can force it to work

Please elaborate.

> inside the routine double *interp( const int length, const int agent )

That is correct, but you never call this routine. It is just sitting idle as good as a dummy.

interp_coeff = interp(..., ...);

will do.