Wanted to play around with Bloc (basic minimum: create a BlElement), followed the basic instructions to fetch the packages here:
Metacello new
baseline: 'Bloc';
repository: 'github://pharo-graphics/Bloc/src';
load
I see the Fetching... being performed and succeed, and then see the Loading baseline... and Loading Bloc progress bars, but then I get thrown into an error:
This package depends on the following classes:
Key
You must resolve these dependencies before you will be able to load these definitions:
Key>>#a
Key>>#arrowDown
Key>>#arrowLeft
Key>>#arrowRight
Key>>#arrowUp
Key>>#b
Key>>#backspace
Key>>#c
Key>>#character:
Any clues?
Update #1:
As it turns out, I should have really read the README, which states pretty clearly that the repo is discontinued.
As Leandro pointed out below, the repo relies on classes (such as Key) that were deprecated after 7.0 (and I can verify that the above worked for me in 7.0)
OTOH, the following, recommended at "the new repo" in 8.0, fails for me with the same problem.
Metacello new
baseline: 'Bloc';
repository: 'github://feenkcom/Bloc/src';
load
Update #2:
After loading a fresh version of Pharo 8.0, the Metacello ... load works for me (my previous image was clearly ... put into a bad state by trying to load the older, invalid version, and now I have to figure out how to undo that damage, but that is a problem for another day).
So, all good now, but I hope the Bloc "booklet" is modified to represent these new version constraints.
Not sure whether this helps but the problem is that the class Key belongs to a deprecated package, namely DeprecatedFileStream.
I was able to load Bloc on Pharo 7.0, where the deprecated classes were still available. Note that in 8.0+ those classes are no longer available.
I'm not a Pharo user, so I cannot provide you with a solution.
That is not the only thing you need. You'll need a different vm and the skia library. It is easier to start with gtoolkit.com to see what you need and how it is built. The vm has some modifications that are not atm in the Pharo vm, for headless usage and no morphic event loop. Skia is used for rendering. In the different github repositories of feenkcom you can find the details. The rendering of bloc to morphic is deprecated.
Related
I just upgraded to the C++ 4.7.2 runtime source and when I build in Xcode, I get the warning
_startToken(startToken) will be initialized after _deleteConfigs(deleteConfigs)
This is in the second constructor of NoViableAltException.
Obviously I can fix this locally (warnings are considered errors in my environment) but this should probably be propagated back into the source tree. I've no idea who does that.
You usually fork ANTLR4 on Github, make your changes and create a pull request from that. You need to have a Github account for that.
However in such a simple case I can probably do the change(s), just give me a patch.
We build our installs\releases using Install Shield. I have come to a situation where we have a patch that cannot be upgraded by a release with a higher version number, that is missing components included in the patch.
After releasing a full minor release (i.e. 7.2.0) we released a patch on a previous full minor release (i.e. 7.1.12).
The Patch 7.1.12 had files and components added that do not exist in 7.2.0. The patch is not uninstallable.
It is now impossible to upgrade 7.1.12 to 7.2.0 because of the missing components. Some customers specifically want to upgrade to 7.2.0 and not a later version (7.3.0) where the components can be added to fix the issue.
Short of uninstalling 7.1.12 and then installing 7.2.0 I couldn’t find any solution to fix.
Is there any way around this? Can we build a 7.1.13 as a bridge to somehow fix the mistake. Or use an argument when installing 7.2.0 to get around this.
I looked around the registry and I am trying to figure out if it is possible to remove the components through the registry.
I tried deleting the component entries in the registry. that didn't do it.
If I delete the product entry in the registry that works - but it must be overkill.
I also tried deleting the patch msi from C:\Windows\Installer but that didn't do it.
There must still be a way to unlink the component from the feature in the registry without deleting the entire product.
It sounds like you're trying to do a series of Minor Upgrades, with at least 7.1.12 delivered as a patch. Using minor upgrades imposes various limitations; anything that requires you to Change the Product Code must be avoided. In your case, note that adding components is allowed, but not the reverse:
The update can add a new component to a new or an existing feature.
The product code must be changed if any of the following are true for the update:
A component is removed from an existing feature.
In short, any modifications to the feature-component tree, other than the addition of new ones, is going to require changing the product code, and thus a Major Upgrade. Major upgrades perform an uninstallation behind the scenes, and thus are less restrictive about the changes they are allowed to deliver.
You have two options:
Use a major upgrade, or some other means of uninstalling the old installation before installing the new version. If possible, this is what I would recommend. Using minor upgrades often adds more difficulty than benefit (though your needs may differ).
Maintain the new components in your newer versions. Note that you do not necessarily have to maintain the resources within them:
The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features.
But you will have to make additional changes to account for the changes to the resources. In your case, this probably will require additions to the RemoveFile table, and may be best served by "puncture component" pattern.
Spelunking through the registry for a workaround that modifies Windows Installer's bookkeeping is a bad idea. It may work, it may appear to work, or it may not work at all. In no case is it supported.
If both versions 7.1.12 and 7.2.0 are already publicly released, you're in a rough spot. I think your best bet there is to re-release 7.2.0 with a new product code and version, e.g. a 7.2.1 major upgrade. You can advise your end users that those already at 7.2.0 don't need to install it.
In the newer examples (seeds, angular.io,..) there is another import for the bootstrapping process: #angular/platform-browser-dynamic.
Could someone explain what the differences are between that and #angular/platform-browser?
There is no information on the official angular.io website yet.
The difference between platform-browser-dynamic and platform-browser is the way your Angular app will be compiled.
Using the dynamic platform makes Angular send the just-in-time compiler to the front-end along with your application. Which means your application is being compiled client-side.
On the other hand, using platform-browser leads to an ahead-of-time pre-compiled version of your application being sent to the browser. Which usually means a significantly smaller package is sent to the browser.
The documentation for bootstrapping explains it in more detail.
platform-browser contains code shared for browser execution (DOM thread, WebWorker)
platform-browser-dynamic contains the client side code that processes templates (bindings, components, ...) and reflective dependency injection
When the offline template compiler is used, platform-browser-dynamic isn't necessary anymore because all reflective access and metadata are converted to generated code.
If you still want to dynamically generate components like shown in https://stackoverflow.com/a/36017067/217408 then you need the dynamic stuff.
If you look closely at the history of the angular2 then you will find there are two version 1) beta version 2) release candidate version. At present it is r.c 3 (release candidate 3). Release candidate version means bug fix releases before the final release. So when angular2 moves to first release candidate version(rc1) from beta version then it make some directory change... for example
angular2/core---->#angular/core
angular2/platform/browser------>#angular/platform-browser-dynamic
I add a snape here
for more information please visit
https://github.com/angular/angular/blob/master/CHANGELOG.md
i Hope you will find your answer. Thanks
I have a ST3 package hosted on GitHub and available through Package Control. It has been superseded by a new package that I wrote, but I keep getting bug reports for the old one since many people are still using it.
What is the correct way to remove the option to install the original package from package control, and ideally from GitHub if possible, without messing anything up for users who currently have the old package installed?
Specifically, will submitting a pull request to Package Control to remove the old package, and/or deleting the old package's github repo, cause the old package to disappear from people's Sublime Text?
I strongly suggest reading through the package developer docs, especially the section entitled Renaming a Package, as they explain everything in detail. Essentially, the easiest path would be to following the directions for renaming a package, and at the same time change the URL to your new Github repo. This way, the old packagecontrol.io page will no longer be available, and upon restart users of the old package should be upgraded to the new one.
I'd also recommend reading through the Package Control Channel's issues to see if this issue has come up before. Worst case scenario, you submit your PR and it gets rejected for some reason, but they'll explain what you need to do differently.
I'm using NuGet to create a 'web framework' package containing code, master pages, css, javascript, etc.
In an attempt to speed up the build / test process I'm running nuget.exe update packages.config but I've noticed that it behaves differently than the package manager console's Update-Package command.
nuget.exe update seems to leave the previous version of the package still installed, resulting in multiple versions of the package installed. This usually doesn't cause problems but the Package-Manager Get-Package command shows many versions installed and sometimes the project will fail to build.
Update-Package actually uninstalls the package then reinstalls it, this is cleaner but slower
My questions are:
1. Is there documentation about the difference / relationship between these commands
2. Is the nuget.exe update behavior of installing multiple versions a bug?
3. Is there a better method for creating a package in one project and updating it in another project in a fast & automated manner?
Unfortunately, there's not much official guidelines or documentation except from piecing together forum and work item threads.
Current package manager console behavior was first included as a result from discussion in this thread, which later derived in a work item (sorry, apparently not enough rep to post more links).
However, as others already noted, behavior is not consistent with nuget.exe, where there's no such switch.
So, in answer to your questions:
VS Package Manager Console and nuget.exe do have different behaviors and seem to be updated independently (which is very unfortunate).
nuget.exe update behavior of installing multiple versions side-by-side has been a design feature from the start, as you can find from a comment on David Ebbo's blog about NuGet command line (again, I would have given you the link, but SO still doesn't trust me).
Unfortunately I haven't found anything about using package manager console cmdlets during build. What you could try is manually deleting all folders with your packageId on a build event and then packaging and installing using nuget.exe. Essentially replicate what Update-Package does manually, since as David Ebbo says, the way you uninstall a package through the command line interface is by, well, deleting the folder (again, can't post a reference, this is a bit annoying...)