The 2 things you would change in Ubot Studio if you could?

[Bot-Factory 602]

Only 2. Keep it short and to the point please.

 

 

1. UI get's unresponsive with large bots.

Better in v4. Even worse in v5

Opening new tabs in v5 takes ages. Memory usage goes up over time. UI crashes from time to time. 

Talking about bots with 20k+ lines. Most of that comes from HTML UIs in my case.

Or bots with 10 or more tabs.

 

2. Multithreading

Adding to global lists and tables is not thread safe. 

Inc / decrement command is not thread safe. 

 

In v5 I get some crashes with some kind of "boost" library. Not sure what that is.

Multithreading doesn't feel "complete" for me at the moment. 

Shared browser with 2-5 windows in parallel works fine most of the time. 

 

But I'm talking about high scaler scrapers with 50-100 threads in parallel. That's when things get starting squishy.

 

 

What are your 2 pain in the b.... things?

 

Dan

 

 

 

[Marton 48]

Ubot 5 is useless for bigger projects, I can't even open any of mine in Ubot 5, and support couldn't either. Both things I would change are related to multithreading (if I can only say two):

 

1. I still think we need more atomic operation variables in Ubot to be able to create complex projects with ease, as mentioned here: http://www.ubotstudio.com/forum/index.php?/topic/16326-threads-and-ubot/

 

2. Browser.exe crashes are still a pain in the ass. There are two types as far as I know: when the browser crashes during operation, and when it can't even be started up ("The

 application was unable to start correctly").

[Kreatus (Ubot Ninja) 422]

1. Better browser than awesomium

2. More api for plugin developers.

[kev123 132]

1. Better browser than awesomium

2. More api for plugin developers.

this

 

to be more specific on 2 open up the browser and ui panel in the api.

[the_way 52]

change it from blue to black.

 

No net authentication on loadup.

[UBot Marketer 7]

1-Canceling V5 and keep adding Features and updating V4

2-Changing the way Ubot Licence Activation  

 

         

 

1- PUT the programming work space outside the Ubot

2- The crashes & and faster loading up .

[CreativeWurks 9]

1. A different browser would likely help with crashes.. Although some users will always have more bugs to report than others. Bugs can be a pain in the @$$ when you have a user base as large as Seth's company..

 

2. The memory consumption can be crazy at times. (There have been some plugins created to help resolve some of this issue.) The overall comsumption can be ultra high at times... but again, this may be all related to the browser issue as stated above.

 

3. Keep Developing and making uBot better and better. So much potential in this software and this company...

 

4. Would be sweet to have compiling on our own side. I'd pay for that for sure..

 

Nevertheless, I believe ubot is great for getting an initial idea out there, making some money with it, then converting it over to a more stable language.. C#... etc. I know of a few members here that have done that when their ubot "bots" went full commercial, and became 'Software'. Probably a good idea to do that if your "bots" get popular.

 

At the end of the day, errors and all...it still helps me cut time and resources by about 25% which is really important to me as a marketer. Ill live with the errors for the overall benefit it offers.

[rocket976 62]

1 Complete developer rebranding

2 Continued updates for v4 the only version we all use... (double edged sword)

[the_way 52]

we would all probably just be happy with a quick porn site link on the toolbar tbh.

[blumi40 222]

we would all probably just be happy with a quick porn site link on the toolbar tbh.

porn site link? we all? did i miss something?

[Marton 48]

No net authentication on loadup.

 

 

2-Changing the way Ubot Licence Activation  

 

 

4. Would be sweet to have compiling on our own side. I'd pay for that for sure..

I don't think it would be wise to change the authentication process, it is understandable why they do it that way. It's needed for them to keep Ubot secure and really hard to crack. And they did a good job on that, as far as I know no cracked version can actually compile the exe file. So why change a working model? (a fully cracked version would cut their income by at least half, which would hurt us in the end, there would be even less updates...)

[the_way 52]

more specifically i mean a silent activation that happens after 10 seconds, so i can get working right away. I know my bloody copy of ubot is legit, and so does the license, so why does it have to tell me that its verified on loadup? just give me a popup that my license is not there, so the program has to close. That would be fine with me. If there is an actual technical limitation on doing this then fine. Is that the cause?

 

If it loaded up the open dialog box, and then i could be browsing for the file i want to open, and by the time i found it, it would have already verified, as a self contained process, before the real ubot is properly loaded into memory.

[UBotDev 276]

If I would only have a chance to pick two, I would choose:

 

1. improve stability

 

2. better error handling (none at the moment)

 

 

To bad this question wasn't asked by the UBot team when they started working on v5....now we ended up with a bunch of features and a version that no one can use.

[the_way 52]

I heard on the grapevine that they will be doing this for V6

 

 

 

To bad this question wasn't asked by the UBot team when they started working on v5....now we ended up with a bunch of features and a version that no one can use.

[Kreatus (Ubot Ninja) 422]

If I am in the position of seth i will purchase the resell rights all the useful plugins released by the members, put it on ubot4 and call it Ubot version 6.

That will get rid of the negativity on ubot5 and boost the sale of ubot since there's a lot of new features.

[the_way 52]

will version 6 be able to make me cups of coffee?

[Seth Turin 223]

* I always wanted compiling on our side. When I bought Ubot, I thought I bought a visual compiler like VB. Just imagine my horror when I learnt the compiling is done on Seth's side and they get hold of our source codes. I don't think they will ever build a compiler version for us because that would make them lose the chances to snoop on our source codes. That brings us to the question: Why do they want to view our source codes which is something really top secret ?

 

* Just how can we convert our bots to more stable language ? What are the steps ? Which members did all this and with which bots ? Where are the links to these bots ?

 

* Ah! You don't mind about the errors but do customers feel such ?

Server-side compiling actually serves two major functions: Makes UBot harder to crack and keeps you from having to download and install a lot more software, some of which may involve paid licenses. But anyway, we get around 1000 compiles per day, and we definitely have better things to do than mine them for secrets.

 

I heard on the grapevine that they will be doing this for V6

Where is this grapevine and why was I not invited?! Seriously, our post-Edward dev strategy is still being formulated, and details have not been discussed outside the team.

 

we would all probably just be happy with a quick porn site link on the toolbar tbh.

lolwut

 

1. Better browser than awesomium

2. More api for plugin developers.

Awesomium does have some annoying issues here and there. It's built on top of the chromium project (which is what chrome is based on), so it's a great deal better than internet explorer. I've seen a firefox-based browser engine floating around that I'd like to look at as well. All browsers have issues. Ultimately I'd like to implement all 3. The technology involved might make that dream hard to chase down.

 

Only 2. Keep it short and to the point please.

 

 

1. UI get's unresponsive with large bots.

Better in v4. Even worse in v5

Opening new tabs in v5 takes ages. Memory usage goes up over time. UI crashes from time to time. 

Talking about bots with 20k+ lines. Most of that comes from HTML UIs in my case.

Or bots with 10 or more tabs.

 

2. Multithreading

Adding to global lists and tables is not thread safe. 

Inc / decrement command is not thread safe. 

 

In v5 I get some crashes with some kind of "boost" library. Not sure what that is.

Multithreading doesn't feel "complete" for me at the moment. 

Shared browser with 2-5 windows in parallel works fine most of the time. 

 

But I'm talking about high scaler scrapers with 50-100 threads in parallel. That's when things get starting squishy.

 

 

What are your 2 pain in the b.... things?

 

Dan

There might be some misunderstanding on the definition of 'thread safe'. In programming, if a variable is not thread safe, it means  that the program will freeze. All the threading issues that I've seen in support have come from a misunderstanding of how threads work in general. And that's not a dig at anyone. Concurrency is one of the most difficult issues in programming. 60 years of programming language development, and even the experts still aren't very good at threading. I will add that I've noticed that UBot 4 does handle threading slightly differently than UBot 5. Neither version does it incorrectly, they just treat is slightly differently, which may be contributing to the confusion. Simplifying threading is one of my major goals moving forward.

 

This is a great thread. It's good to see where people's heads are on this stuff. There are some interesting ideas in here that I might have to think about more.

[a2mateit 395]

1.  Don't abandon version 4...  I won't use v5 until it's stable, and I stopped paying for updates because I refuse to pay to be a beta tester.

 

2.  Fix the browser.exe crash

[Kreatus (Ubot Ninja) 422]

Glad to see you responding to your customers Seth. Hope to see more updates from you just like the good old days of ubot..

[Pete 121]

Server-side compiling actually serves two major functions: Makes UBot harder to crack and keeps you from having to download and install a lot more software,

Also stops us from selling .exes to big companies, because you can't hide the fact you use ubotstudio  software from them. But as soon as there are aware our software needs to call home to start and compile the .exe and some of there data could be included within that it's a deal over.

[Bot-Factory 602]

Also stops us from selling .exes to big companies, because you can't hide the fact you use ubotstudio  software from them. But as soon as there are aware our software needs to call home to start and compile the .exe and some of there data could be included within that it's a deal over.

 

Server Side Compiling isn't the problem. As long as the compiled version would include everything and would not call home, everything should be fine. 

There just should be a way to include all the necessary components into the installer and allow the compiled version to run without calling home. 

 

Dan

[UBotDev 276]

There might be some misunderstanding on the definition of 'thread safe'. In programming, if a variable is not thread safe, it means  that the program will freeze. All the threading issues that I've seen in support have come from a misunderstanding of how threads work in general. And that's not a dig at anyone. Concurrency is one of the most difficult issues in programming. 60 years of programming language development, and even the experts still aren't very good at threading. I will add that I've noticed that UBot 4 does handle threading slightly differently than UBot 5. Neither version does it incorrectly, they just treat is slightly differently, which may be contributing to the confusion. Simplifying threading is one of my major goals moving forward.

 

Seth, can you then please explain this behavior?

 

I think the problem has been ignored and swept under the carpet for too long (http://tracker.ubotstudio.com/issues/208), and I think in v5 it would be time you do something about it.

[Bot-Factory 602]

Seth, can you then please explain this behavior?

 

I think the problem has been ignored and swept under the carpet for too long (http://tracker.ubotstudio.com/issues/208), and I think in v5 it would be time you do something about it.

 

And adding a wait command as mentioned in the tracker is not really a solution. If my case, threads executes very fast, a wait would decrease performance a lot.

Just imagine I need to scrape 2 Million pages. When I add a 0.5 wait for every thread, that's a total of additional time.

 

And when the threads execute faster than the wait time, I will never reach 50 or more threads in parallel. 

That thinking only works if threads take a while to execute. In a shared browser scenario where you navigate through a page and stuff like that.

 

Then this workaround is fine. 

 

But when I talk about threads, I talk about a high scale scraper. Which is using 50+ threads in parallel and where each thread finishes in under 1 second. 

Together with HTTP plugin or socket commands threading is a completely different game.

 

I think that is the problem here. You can not apply the "old" threading methods, where a shared browser runs for 30 seconds, for those high scale scenario.

 

 

So when you design or test threading you should add that scenario to your list. 

1 Million pages to scrape

50+ threads in parallel

Each thread executes in under 1 / 0.5 seconds.

Each thread scrapes 100 items and needs to add that to a global list. 

 

If that works, then threading works. The shared browser stuff is still massage and not heart surgery :-)

 

Dan

[kev123 132]

Seth although I agree and your definition on thread safe there's possibly more detail than just not locking up. I would say its also stopping concurrent invocations interfering with one another(which you could argue is the same thing but wouldn't cause the app to freeze).

 

What also makes the term "thread safe" on the forum more confusing is people are actually talking about two different scenarios and packaging it up in one term.

 

The two different issues people refer to is 1.concurrent access to variables lists etc  2.values being shared between threads.

 

If I take 1. for example one issue I believe variable increment/decrement and the issue with concurrent access when threading has been raised by a tracker item(there is also a plugin to fix the issue that works well). Respect to your support team there on the front line for your company and help a lot of your users but i'm not sure there understanding is as high as some users. The feedback on the tracker was to add a delay on the thread initialise part of code.

 

I think you will agree adding a delay only decreases the chance of concurrent access and isn't a fix for threading access. If I take for example http multithread adding a one second delay in the thread initialise loop in affect makes it a single thread bot because threads finish often in under a second.

 

 

on the browser GeckoFX beasts the aw browser all day long. Recently used it in a app a dev friend had created and there's no browser issues running eight days non stop. i'm going to use it in all my c# projects going forward.

[the_way 52]

This thread should be closed now, its lost the spirit of Dan's original question now, and is becoming a vacuum for complaints.