Mon approche. Le noyau est le moteur. - page 165

Nouveau commentaire
 
Dmitry Fedoseev:

Je suppose que oui. Mais si une interface graphique, c'est un autre dossier, et ce n'est pas possible sur le marché.

Peut-être bien. Je ne sais pas. Mais je pense que ce problème peut être résolu, si Pyotr a quelque chose de valeur.
Vous devrez envoyer un fichier à la place de marché, vous n'avez pas besoin d'envoyer le moteur, et il fonctionnera sans le moteur.
Peter, ou est-ce que je comprends mal quelque chose ?
 
Nikolai Semko:
Peut-être. Je ne sais pas. Mais je pense que ce problème est soluble si Peter a quelque chose de valeur.
Vous devrez envoyer un seul fichier à la place de marché, vous n'avez pas besoin d'envoyer le moteur, et il fonctionnera sans le moteur.
Pyotr, ou est-ce que je comprends mal quelque chose ?

Tu as raison, Nikolay. Le conseiller expert fonctionne sans le moteur. Le moteur crée l'interface graphique de l'EA dès que l'EA est placé sur un graphique séparé et reçoit des commandes de celui-ci. Le moteur peut basculer entre différents EA. Lors de la commutation, il recharge simplement un autre noyau à partir d'un fichier texte. Vous pouvez le laisser en place, mais attribuez-lui un tableau séparé et gardez-le en permanence.

 
Il existe une idée pour éviter à l'utilisateur de devoir trimballer le fichier du noyau partout pour que le moteur le télécharge. Lors de la production d'une interface graphique, le constructeur produit un fichier noyau. Au lieu d'enregistrer dans un fichier, le constructeur peut enregistrer le noyau dans une ressource et écrire une chaîne de connexion pour cette ressource dans le fichier des propriétés conventionnelles. Lorsque l'utilisateur connecte le fichier de propriétés de connexion créé, cette ressource sera intégrée au noyau lors de l'initialisation de son EA. Ensuite, lors de la connexion au moteur, ce dernier lira simplement la ressource avec le noyau de l'EA et jouera l'interface graphique. Ainsi, il ne sera pas nécessaire de trimballer des fichiers avec le noyau.
 
Maxim Kuznetsov:

Selon les règles actuelles, les produits ayant des dépendances supplémentaires ne peuvent pas être distribués via la place de marché. En outre, je soupçonne que cela est légalement interdit ou plutôt difficile.

Les bibliothèques ex* externes ne peuvent pas être utilisées, y compris celles qui ne contiennent pas d'appels à la dll. Cependant, les indicateurs, tels que le moteur de Peter, ne sont pas soumis à cette restriction.

 
Vasiliy Sokolov:

Les bibliothèques ex* externes ne peuvent pas être utilisées, y compris celles qui ne contiennent pas d'appels à la dll. Toutefois, cette limitation ne s'applique pas aux indicateurs, tels que le moteur de Peter.

Je me suis intéressé spécifiquement à cette question en interrogeant le marché des services d'assistance. La réponse a été très claire, mais pas très heureuse :-) le produit du marché doit être une chose en soi et ne pas nécessiter l'installation d'autres composants. Tous les indicateurs et bibliothèques nécessaires doivent être entassés à l'intérieur via les ressources.

Ce qui est logique - une personne a acheté un produit et le produit (et toutes ses revendications) devrait être immédiatement disponible sans travail supplémentaire.
Et il n'y a pas eu de situation où une certaine dépendance a été mise à jour, mais où le conseiller expert est tombé :-)

 

Et en général, le commerce l'est :

mes revenus - "core - engine"

;)
 
Реter Konow:
Il y a une idée pour éviter à l'utilisateur de devoir trimballer le fichier du noyau partout pour que le moteur puisse le télécharger. Lors de la production d'une interface graphique, le constructeur produit un fichier kernel. Au lieu d'enregistrer dans un fichier, le constructeur peut enregistrer le noyau dans une ressource et écrire une chaîne pour connecter cette ressource dans le fichier de propriétés du noyau. Lorsque l'utilisateur connecte le fichier de propriétés de connexion créé, cette ressource sera intégrée au noyau lors de l'initialisation de son EA. Ensuite, lors de la connexion au moteur, ce dernier lira simplement la ressource avec le noyau de l'EA et jouera l'interface graphique. Ainsi, il ne sera pas nécessaire de faire glisser les fichiers du noyau.
Oh mec, je pensais que c'était comme ça que c'était implémenté. Bien sûr, quel est l'intérêt de transporter des fichiers de configuration avec soi ?
Et imagine, Peter, que tu peux aussi rassembler le moteur dans un fichier ex* commun en tant que classe.
Et pas de sept* à six ailes :))
 
Nikolai Semko:
Oh, mon Dieu, je pensais que c'était mis en place à votre façon. Bien sûr, quel est l'intérêt de transporter vos fichiers de configuration.
Et imagine, Peter, que tu peux aussi rassembler le moteur dans un fichier ex* commun en tant que classe.
Et pas de sept* à six ailes :))

Pouvez-vous la décrire plus en détail ? Comment, quoi et pourquoi.

 
Nikolai Semko:
...
Et imagine, Peter, que tu peux aussi rassembler le moteur dans un fichier ex* commun en tant que classe.
...

Nikolaï, si tu suggères d'ouvrir le code du moteur pour que tout le monde puisse le mettre dans l'EA, alors j'y ai pensé. Hélas, cela mettrait une limite au développement du moteur. Tout se passerait dans un seul thread d'application, ce qui limiterait les ressources utilisées et la plupart des avantages que l'on peut obtenir en parallélisant le calcul seraient perdus. En outre, les utilisateurs commenceront à apporter des modifications au moteur et à distribuer des versions modifiées, ce qui créera le chaos et de nouveaux problèmes de développement.

Par conséquent, l'idée est bonne en théorie, mais en pratique, hélas...(.

 
Реter Konow:

Nikolaï, si tu suggères d'ouvrir le code du moteur pour que tout le monde puisse le mettre dans l'EA, alors j'y ai pensé. Hélas, cela mettrait une limite au développement du moteur. Tout se passerait dans un seul thread d'application, ce qui limiterait les ressources utilisées et la plupart des avantages que l'on peut obtenir en parallélisant le calcul seraient perdus. En outre, les utilisateurs commenceront à apporter des modifications au moteur et à distribuer des versions modifiées, ce qui créera le chaos et de nouveaux problèmes de développement.

Par conséquent, l'idée est bonne en théorie, mais en pratique, hélas...(.

Peter, où est la preuve ?
Où est le rapport de recherche comparant la vitesse d'exécution d'un programme dans un seul thread ex5 (il est même inutile d'expérimenter avec ex4) et dans deux threads ?
C'était juste une supposition hypothétique, qui, d'ailleurs, a été énoncée pour la première fois par moi (ici) quand je n'ai pas réussi à obtenir de vous au moins une formulation des avantages de votre approche.
Vous utilisez déjà mon hypothèse comme un fait.
Personnellement, j'admets qu'il peut y avoir un avantage, mais par pure intuition (et non par connaissance) je parie à 75% que cela ne donnera aucun avantage, puisque l'interaction et l'échange de données entre les deux programmes n'est pas libre, et que le processeur est unique pour les deux ex5. Mais la réponse à cette question ne peut être donnée que par les développeurs eux-mêmes ou par une expérience qualitative.
1...158159160161162163164165166167168169170171172...184
Nouveau commentaire
Raison: