EPTDo I make another process that gets the user list from the server and sends this back to the gui? That sounds somewhat complicated.
The Big Programming Thread - Page 824
| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
|
Nyxisto
Germany6287 Posts
Do I make another process that gets the user list from the server and sends this back to the gui? That sounds somewhat complicated. | ||
|
mantequilla
Turkey781 Posts
in json format: { "type": "message", "content": "hello!" } or { "type": "userList", "content": "Alice, John" } | ||
|
Nyxisto
Germany6287 Posts
| ||
|
mantequilla
Turkey781 Posts
this is similar to the way that all web requests work, only difference is you are using stdin/stdout instead of a tcp connection  | ||
|
Nyxisto
Germany6287 Posts
| ||
|
Manit0u
Poland17794 Posts
On January 04 2017 02:27 tofucake wrote: Old datatables was awful. New datatables is pretty nice Have you ever tried them alongside materialize with responsive tables? I'm living in a nightmare for the past few days. I've even solved the async mailer library being incompatible with user authentication library problem just to get out of this shit for a moment... Edit: I mean, why the fuck in this day and age they would go for changing the style attribute of column cells and setting their width in pixel values, along with absolute positioning everywhere? What in the actual fuck?! How am I supposed to work with this shit that just pretends to be responsive? (I'm using DataTables 1.10.10) The funniest thing is, including the DataTables.responsive extras and doing responsive: true, in the set-up actually makes it worse. Seriously, fuck that shit. Why don't front-end people rebel at such blatant violation of all good practices? | ||
|
Nyxisto
Germany6287 Posts
Problem is that this only updates if someone tries to send a message because that's the only time the sockets are being tested. My hacky solution was to basically generate a "quit key" that is being send to the server when the client quits the app. I assume there's some better way to do this? | ||
|
Blisse
Canada3710 Posts
On January 05 2017 08:54 Nyxisto wrote: A new problem has cropped up in my chat client. The way this works at the moment is that I basically iterate over the sockets and if I receive anything the server will broadcast it, if some client is not available I'll catch that and drop the client from the socket list. Problem is that this only updates if someone tries to send a message because that's the only time the sockets are being tested. My hacky solution was to basically generate a "quit key" that is being send to the server when the client quits the app. I assume there's some better way to do this? I don't really understand your problem but everything you seem to be doing looks like enforcing a protocol for communicating within your network, and stuff like that already exists because it's common. https://en.wikipedia.org/wiki/JSON-RPC https://en.wikipedia.org/wiki/IRCd Some of your other "problems" just seem like problems with C/C++ async design, which is to say pretty poor multi-threading - polling, disconnects, updates (assuming you're using C++ cause you used stdin). | ||
|
RoomOfMush
1296 Posts
On January 05 2017 08:54 Nyxisto wrote: A new problem has cropped up in my chat client. The way this works at the moment is that I basically iterate over the sockets and if I receive anything the server will broadcast it, if some client is not available I'll catch that and drop the client from the socket list. Problem is that this only updates if someone tries to send a message because that's the only time the sockets are being tested. My hacky solution was to basically generate a "quit key" that is being send to the server when the client quits the app. I assume there's some better way to do this? What language do you use? What methods do you use to "test" your sockets? Usually a socket should tell you when the connection has been closed. In java, for example, a TCP socket will throw an exeption when it discovers the other side is unavailable. | ||
|
Manit0u
Poland17794 Posts
Everything now works, is a lot simpler, a lot more maintainable and more reusable. It's also more than 6x faster. | ||
|
Deleted User 3420
24492 Posts
What is the difference between "iteration" and "search". I understand that iteration means to go through each element 1 by 1. For example on this page: http://bigocheatsheet.com/ Hash Table has O(1) for "search". It uses the hashcode to find the element. Array has O(n) for "search". in this case, is "search" the same as iteration? If so, I am wondering how hash tables compare to other data structures in terms of iteration? Is iteration slower with a hashset because it likely contains empty buckets? And does this mean that if I need a data structure where I have to iterate to find what I want, I should use an arraylist? What I need to do is find elements based on criteria (not the element itself, just some field the element has). I then need to remove those elements. oh, and a map won't work because of the nature of the criteria edit: (I realize that I am using hash table and hashset interchangeably here when they are different structures, but I am guessing it doesn't matter for iteration? if it does, why?) | ||
|
RoomOfMush
1296 Posts
On January 06 2017 04:15 travis wrote: I am a bit confused about data structure complexity when it comes to iteration. What is the difference between "iteration" and "search". I understand that iteration means to go through each element 1 by 1. For example on this page: http://bigocheatsheet.com/ Hash Table has O(1) for "search". It uses the hashcode to find the element. Array has O(n) for "search". in this case, is "search" the same as iteration? If so, I am wondering how hash tables compare to other data structures in terms of iteration? Is iteration slower with a hashset because it likely contains empty buckets? And does this mean that if I need a data structure where I have to iterate to find what I want, I should use an arraylist? What I need to do is find elements based on criteria (not the element itself, just some field the element has). I then need to remove those elements. oh, and a map won't work because of the nature of the criteria edit: (I realize that I am using hash table and hashset interchangeably here when they are different structures, but I am guessing it doesn't matter for iteration? if it does, why?) What that website refers to as "search" is probably a contains check for a given element. "Does the data structure contain a particular element?". This is something that all hash-based data structures are particularly good at since they have been made exactly for this purpose. If you want to iterate over all elements within a data structure nothing will ever beat an array in terms of performance. ArrayList in java is using an array in the background and thus very fast for iterations. However, the HashMap (not HashTable!) also uses an array (more or less. Its complicated) and isnt that much slower. It should usually not make any difference. Dont worry about it unless you actually encounter problems with performance or you are explicitly working on an algorithm which needs to perform well for millions of elements. The worst data structure for iterations is probably a linked list. This has nothing to do with the theoretic aspect of the linked list (since it is very good in theory!) but with the way modern hardware works. A linked list is very very hard to predict for the computer since each node could be at completely random points within the computers memory while an array traditionally has all of its elements tightly packed. Prediction is a big thing with hardware in modern times. By the way: A HashSet is usually build by using a HashMap internally so it really doesnt matter. Even if the Set is build from scratch it probably does much of the same thing as the Map. The difference, if any, should be insignificant. | ||
|
slmw
Finland233 Posts
On January 06 2017 04:52 RoomOfMush wrote: The worst data structure for iterations is probably a linked list. This has nothing to do with the theoretic aspect of the linked list (since it is very good in theory!) but with the way modern hardware works. A linked list is very very hard to predict for the computer since each node could be at completely random points within the computers memory while an array traditionally has all of its elements tightly packed. Prediction is a big thing with hardware in modern times. I would say the logarithmic factor from a binary tree makes it a lot slower, and the empty buckets in hash sets slow things down as well. Neither of these data structures are 'tightly packed'. | ||
|
RoomOfMush
1296 Posts
On January 06 2017 10:35 slmw wrote: I would say the logarithmic factor from a binary tree makes it a lot slower, and the empty buckets in hash sets slow things down as well. Neither of these data structures are 'tightly packed'. It is true that the empty buckets have an impact on speed, but in the average case the number of empty buckets is usually not very big. It still is an array iteration though (assuming the regular java HashMap implementation of course) and those are relatively fast. But why do you say iterating a binary tree has a logarithmic factor to it? The worst case for a binary tree is a linked list. I do not see how this would be anything but linear time. | ||
|
zf
231 Posts
On January 06 2017 19:33 RoomOfMush wrote: But why do you say iterating a binary tree has a logarithmic factor to it? The worst case for a binary tree is a linked list. I do not see how this would be anything but linear time. Average search time is logarithmic. | ||
|
RoomOfMush
1296 Posts
But travis and I were talking about iterating all elements. | ||
|
slmw
Finland233 Posts
Edit: Which is also O(N), so it's just the same as an in-order traversal of a tree. A few more steps involved than in iterating a linked list though. | ||
|
Deleted User 3420
24492 Posts
i guess it would be rude to completely delete this. my question was about using recursion to find the smallest finite line segment among many finite line segments on a plane, that does not intersect any other line segments. | ||
|
spinesheath
Germany8679 Posts
Then in the second step, you iterate over the sorted lines. For each line, you check it against all lines, which you do again by iterating over the sorted lines, skipping the one you're currently checking. If you find one that doesn't intersect any line, you return that one as a result. It is the smallest one because it's the first in the sorted list. There is no recursion here. It's a naive approach, but clean and simple. It's O(n^2). More sophisticated approaches probably would keep the first part, but tweak the second part to use sort of a divide and conquer approach, but that won't be very simple at all. I can imagine O(n log n), but I don't know if it actually is possible. This approach includes a number of pointless checks, in the worst case 50%. This is because I check against all lines without skipping the pairs already covered. We can avoid that easily by storing the sorted lines in a list, then iterate over the list by index. If we are currently at list[5], we only check against list[6] and beyond: Still is O(n^2) though. Always ask yourself if you can split your problem into smaller chunks. Sort first, check after. Simple approach first, optimization after. Also Java or rather the JVM is not well equipped for heavy recursion. Don't avoid recursion at all costs, but if you're doing a lot of work with deep recursion, you probably should try to avoid it. | ||
|
RoomOfMush
1296 Posts
On January 07 2017 02:44 spinesheath wrote: Always ask yourself if you can split your problem into smaller chunks. Sort first, check after. Simple approach first, optimization after. Another improvement would be to remove all lines that intersect any other line after each pass. This will make consecutive passes faster in a bad case with many intersecting lines. (in a case with few intersecting lines we will stop early anyways) On January 07 2017 02:44 spinesheath wrote: Also Java or rather the JVM is not well equipped for heavy recursion. Don't avoid recursion at all costs, but if you're doing a lot of work with deep recursion, you probably should try to avoid it. There is some Just-In-Time optimizations which unroll the recursion but those are not quite at the level of the magic functional programming languages do so I agree. | ||
| ||
