You want to do amateur or power-level computing? Then there is no other choice than Windows! Period. As a Windows user you don't have to spend tons of a money for a Mac PC (sorry Mac guys but Mac is nothing else than an expensive PC now) and you don't have to waste time on forums to learn how install stuff. All that Linux/Mac can offer you can get on Windows and get is better. I spent many years working with Linux but it was always only my second choice. Sorry Linux friends, but I said it.
Showing posts with label bugs. Show all posts
Showing posts with label bugs. Show all posts
Saturday, August 6, 2016
Embarcadero finally decided to fix SOME bugs in Delphi
In the new road map, Embarcadero finally decided to fix SOME bugs in Delphi.
It seems good news but hold your horses:
1. They not always keep their promise related to the road map.
2. There are not so many bugs
3. They won't do all the fixes at once, but until 2018
4. Until 2018 another 500 new bugs (AT LEAST) will be introduced
5. We have to pay (not 59 bucks but HARD money) to get that non-buggy version of Delphi.
And in the end, what the fuck are we so happy that Embarcadero is fixing some bugs? Is not a present, a gift from heavens! Those bugs SHOULD NOT BE THERE anyway!
So, thank you Embarcadero for finally thinking to fix some bugs and FUCK YOU.
PS: In the next road map maybe you will introduce an item likes "free updates".
http://community.embarcadero.com/article/news/16418-product-roadmap-august-2016
Labels:
borland,
bug,
bug fix,
bugs,
crash,
customer,
delphi,
delphi roadmap,
embarcadero,
free,
fuck you embarcadero,
money,
paid,
road map,
unhappy,
update
Monday, March 11, 2013
More nasty bugs related to Delphi packages
The problem
My Delphi XE started to act strange lately. I have unit Unit2.pas that uses 'FormatBytes' declared in Unit1.pas. When I try to compile Unit2 Delphi says that it cannot find FormatBytes. But FormatBytes is there, in Unit1 !!
Unit1 belongs to Package1 and Unit2 to Package2 (Package2 depends on Package1).
Even more strange: if I delete Unit1 (pas and dcu) Delphi doesn't complain that it cannot find the unit! Its like Unit1 has been cached somewhere. However, if I try to open Unit1, obviously it cannot be found and Delphi popups a OpenDialog to let me show there Unit1 is located.
I know there is already a bug in the caching system for VCL. I guess this is a similar bug.
Update
Solution: I deleted all files related to all my packages:
(Note: Initially I tried deleting files specified above except Dproj and paths and it didn't worked)
My Delphi XE started to act strange lately. I have unit Unit2.pas that uses 'FormatBytes' declared in Unit1.pas. When I try to compile Unit2 Delphi says that it cannot find FormatBytes. But FormatBytes is there, in Unit1 !!
Unit1 belongs to Package1 and Unit2 to Package2 (Package2 depends on Package1).
Even more strange: if I delete Unit1 (pas and dcu) Delphi doesn't complain that it cannot find the unit! Its like Unit1 has been cached somewhere. However, if I try to open Unit1, obviously it cannot be found and Delphi popups a OpenDialog to let me show there Unit1 is located.
I know there is already a bug in the caching system for VCL. I guess this is a similar bug.
Update
Solution: I deleted all files related to all my packages:
- DCP
- BPL
- DCU
- DSK
- DPROJ
- paths from 'Library'
(Note: Initially I tried deleting files specified above except Dproj and paths and it didn't worked)
Tuesday, January 8, 2013
Google Drive still unreliable (How to fix 'Primary key must be unique' error)
I hate Google Drive. It is haunted by too many bugs.
Recently my GDrive application started showing a "primary key must be unique" error message, asking me to disconnect the drive and start all over again. I did that. Took few hours to resynchronize it all. But the next day I got the same error and asked me again to repeat the operation. I have been poking the forums (including Google's forum) up and down for months and found no real solution. So I had to do the job on my own. This is how to fix the "primary key must be unique" error:
Update 1 - How to do it on Mac OS (thanks to Maik):
Thanks, this fix also works for Apple Mac OS-X.
To get to the log file:
- in finder click the Go menu
- with the menu open click ALT-key so the hidden Library item appears
- open the Library and go to folder Google -> Drive
Update 2 - More GDrive bugs: The trash cannot be purged
Now my Google Drive account shows that is 95% full even if I don't have many files loaded in GDrive (I have a total of 1.1GB). After investigation I have discovered that are files locked in the 'Trash' that cannot be deleted. I contacted Google Drive support and they said they will fix my account. The provided additional Google Drive space so I can keep using my GDrive until they will fix the problem. That was in February 2012. Still no word from them.
Update 3 - How to make GDrive synchronize faster?
Related
How to improve the Google Drive synchronize speed?
_______________
With this occasion I want to thanks Google team for the fucking 'good' job they did and to tell them: I don't believe in witches, but they surely exist.
Recently my GDrive application started showing a "primary key must be unique" error message, asking me to disconnect the drive and start all over again. I did that. Took few hours to resynchronize it all. But the next day I got the same error and asked me again to repeat the operation. I have been poking the forums (including Google's forum) up and down for months and found no real solution. So I had to do the job on my own. This is how to fix the "primary key must be unique" error:
- Start Google Drive
- Hold the SHIFT key pressed while clicking the Google Drive systray icon. This will show the 'Enable diagnostic mode' special menu.
- Click 'Enable diagnostic mode' menu.
- Wait until Google Drive crashes and shows the "primary key must be unique"error message. Let the application shutdown.
- Go to "c:\Users\YOUR_USER_NAME\AppData\Local\Google\Drive" folder and open "sync_log.log".
Note: Replace 'YOUR_USER_NAME' with your Windows account name (the account in which you are logged in). You can see this name when you press the 'Start' button. - Look up this text: "Detected conflict while trying to download file to".
- After 'to' follows the name of the file that generated the conflict. Locate that file and delete it or (better) rename it. Do this for all conflicted files (if there are more than one).
- Restart Google Drive.
That's it.
Update 1 - How to do it on Mac OS (thanks to Maik):
Thanks, this fix also works for Apple Mac OS-X.
To get to the log file:
- in finder click the Go menu
- with the menu open click ALT-key so the hidden Library item appears
- open the Library and go to folder Google -> Drive
Update 2 - More GDrive bugs: The trash cannot be purged
Now my Google Drive account shows that is 95% full even if I don't have many files loaded in GDrive (I have a total of 1.1GB). After investigation I have discovered that are files locked in the 'Trash' that cannot be deleted. I contacted Google Drive support and they said they will fix my account. The provided additional Google Drive space so I can keep using my GDrive until they will fix the problem. That was in February 2012. Still no word from them.
Update 3 - How to make GDrive synchronize faster?
Related
How to improve the Google Drive synchronize speed?
_______________
With this occasion I want to thanks Google team for the fucking 'good' job they did and to tell them: I don't believe in witches, but they surely exist.
Labels:
bugs,
error,
gdrive,
google drive,
software,
synchronize
Subscribe to:
Posts (Atom)